The Mullvad VPN client app for desktop and mobile

Last update: May 24, 2022

Mullvad VPN desktop and mobile app

Welcome to the Mullvad VPN client app. This repository contains all the source code for the desktop and mobile versions of the app. For desktop this includes the system service/daemon (mullvad-daemon), a graphical user interface (GUI) and a command line interface (CLI). The Android app uses the same backing system service for the tunnel and security but has a dedicated frontend in android/. iOS consists of a completely standalone implementation that resides in ios/.


There are built and signed releases for macOS, Windows, Linux and Android available on our website and on Github. The Android app is also available on Google Play and F-Droid and the iOS version on App Store.

You can find our code signing keys as well as instructions for how to cryptographically verify your download on Mullvad's Open Source page.

Platform/OS support

These are the operating systems and their versions that the app officially supports. It might work on many more versions, but we don't test for those and can't guarantee the quality or security.

OS/Platform Supported versions
Windows 7, 8.1 and 10
macOS The three latest major releases
Linux (Ubuntu) The two newest LTS releases and the two newest non-LTS releases
Linux (Fedora) The versions that are not yet EOL
Linux (Debian) The versions that are not yet EOL
Android The four latest major releases
iOS 13 and newer

On Linux we test using the Gnome desktop environment. The app should, and probably does work in other DEs, but we don't regularly test those.


Here is a table containing the features of the app across platforms. This reflects the current state of latest master, not necessarily any existing release.

Windows Linux macOS Android iOS
OpenVPN over Shadowsocks
Optional local network access ✓*

* The local network is always accessible on iOS with the current implementation

Security and anonymity

This app is a privacy preserving VPN client. As such it goes to great lengths to stop traffic leaks. And basically all settings default to the more secure/private option. The user has to explicitly allow more loose rules if desired. See the dedicated security document for details on what the app blocks and allows, as well as how it does it.

Checking out the code

This repository contains submodules needed for building the app. However, some of those submodules also have further submodules that are quite large and not needed to build the app. So unless you want the source code for OpenSSL, OpenVPN and a few other projects you should avoid a recursive clone of the repository. Instead clone the repository normally and then get one level of submodules:

git clone
cd mullvadvpn-app
git submodule update --init

We sign every commit on the master branch as well as our release tags. If you would like to verify your checkout, you can find our developer keys on Mullvad's Open Source page.

Binaries submodule

This repository has a git submodule at dist-assets/binaries. This submodule contains binaries and build scripts for third party code we need to bundle with the app. Such as OpenVPN, Shadowsocks etc.

This submodule conforms to the same integrity/security standards as this repository. Every merge commit should be signed. And this main repository should only ever point to a signed merge commit of the binaries submodule.

See the binaries submodule's README for more details about that repository.

Install toolchains and dependencies

Follow the instructions for your platform, and then the All platforms instructions.

These instructions are probably not complete. If you find something more that needs installing on your platform please submit an issue or a pull request.


The host has to have the following installed:

  • Microsoft's Build Tools for Visual Studio 2019 (a regular installation of Visual Studio 2019 Community edition works as well).

  • Windows 10 SDK.

  • msbuild.exe available in %PATH%. If you installed Visual Studio Community edition, the binary can be found under:

    C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\amd64
  • bash installed as well as a few base unix utilities, including sed and tail. The environment coming with Git for Windows works fine.

  • gcc for CGo.



# For building the daemon
sudo apt install gcc libdbus-1-dev
# For building the installer
sudo apt install rpm


# For building the daemon
sudo dnf install dbus-devel
# For building the installer
sudo dnf install rpm-build


These instructions are for building the app for Android under Linux.

Download and install the JDK

sudo apt install zip default-jdk

Download and install the SDK

The SDK should be placed in a separate directory, like for example ~/android or /opt/android. This directory should be exported as the $ANDROID_HOME environment variable.

cd /opt/android     # Or some other directory to place the Android SDK

./tools/bin/sdkmanager "platforms;android-29" "build-tools;29.0.3" "platform-tools"

If sdkmanager fails to find the SDK root path, pass the option --sdk_root=$ANDROID_HOME to the command above.

Download and install the NDK

The NDK should be placed in a separate directory, which can be inside the $ANDROID_HOME or in a completely separate path. The extracted directory must be exported as the $ANDROID_NDK_HOME environment variable.

cd "$ANDROID_HOME"  # Or some other directory to place the Android NDK

cd android-ndk-r20b


Docker is required to build wireguard-go for Android. Follow the installation instructions for your distribution.

Configuring Rust

These steps has to be done after you have installed Rust in the section below:

Install the Rust Android target

Some environment variables must be exported so that some Rust dependencies can be cross-compiled correctly:

export NDK_TOOLCHAIN_DIR="$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/linux-x86_64/bin"
export AR_aarch64_linux_android="$NDK_TOOLCHAIN_DIR/aarch64-linux-android-ar"
export AR_armv7_linux_androideabi="$NDK_TOOLCHAIN_DIR/arm-linux-androideabi-ar"
export AR_x86_64_linux_android="$NDK_TOOLCHAIN_DIR/x86_64-linux-android-ar"
export AR_i686_linux_android="$NDK_TOOLCHAIN_DIR/i686-linux-android-ar"
export CC_aarch64_linux_android="$NDK_TOOLCHAIN_DIR/aarch64-linux-android21-clang"
export CC_armv7_linux_androideabi="$NDK_TOOLCHAIN_DIR/armv7a-linux-androideabi21-clang"
export CC_x86_64_linux_android="$NDK_TOOLCHAIN_DIR/x86_64-linux-android21-clang"
export CC_i686_linux_android="$NDK_TOOLCHAIN_DIR/i686-linux-android21-clang"
rustup target add aarch64-linux-android armv7-linux-androideabi i686-linux-android x86_64-linux-android
Set up cargo to use the correct linker and archiver

This block assumes you installed everything under /opt/android, but you can install it wherever you want as long as the ANDROID_HOME variable is set accordingly.

Add to ~/.cargo/config.toml:

ar = "/opt/android/android-ndk-r20b/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android-ar"
linker = "/opt/android/android-ndk-r20b/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android21-clang"

ar = "/opt/android/android-ndk-r20b/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-ar"
linker = "/opt/android/android-ndk-r20b/toolchains/llvm/prebuilt/linux-x86_64/bin/armv7a-linux-androideabi21-clang"

ar = "/opt/android/android-ndk-r20b/toolchains/llvm/prebuilt/linux-x86_64/bin/x86_64-linux-android-ar"
linker = "/opt/android/android-ndk-r20b/toolchains/llvm/prebuilt/linux-x86_64/bin/x86_64-linux-android21-clang"

ar = "/opt/android/android-ndk-r20b/toolchains/llvm/prebuilt/linux-x86_64/bin/i686-linux-android-ar"
linker = "/opt/android/android-ndk-r20b/toolchains/llvm/prebuilt/linux-x86_64/bin/i686-linux-android21-clang"

Signing key for release APKs (optional)

In order to build release APKs, they need to be signed. First, a signing key must be generated and stored in a keystore file. In the example below, the keystore file will be /home/user/app-keys.jks and will contain a key called release.

keytool -genkey -v -keystore /home/user/app-keys.jks -alias release -keyalg RSA -keysize 4096 -validity 10000

Fill in the requested information to generate the key and the keystore file. Suppose the file was protected by a password keystore-password and the key with a password key-password. This information should then be added to the android/ file:

keyAlias = release
keyPassword = key-password
storeFile = /home/user/app-keys.jks
storePassword = keystore-password

All platforms

  1. Make sure to use a recent version of bash. The default version in macOS (3.2.57) isn't supported.

  2. Get the latest stable Rust toolchain via

  3. This can be skipped for Android builds.

    Get the latest version 14 release of Node.js and the latest version of npm. After installing Node.js the latest version of npm can be installed by running:

    npm install -g npm


    brew install node


    Just download and unpack the node-v14.xxxx.tar.xz tarball and add its bin directory to your PATH.


    Download the Node.js installer from the official website.

  4. Install Go (ideally version 1.16) by following the official instructions. Newer versions may work too. Since cgo is being used, make sure to have a C compiler in your path. On Windows mingw's gcc compiler should work. gcc on most Linux distributions should work, and clang for MacOS.

Building and packaging the app


The simplest way to build the entire app and generate an installer is to just run the build script. --dev-build is added to skip some release checks and signing of the binaries:

./ --dev-build

This should produce an installer exe, pkg or rpm+deb file in the dist/ directory.

Building this requires at least 1GB of memory.


By default a universal app is built on macOS. To build specifically for x86_64 or ARM64 add --target x86_64-apple-darwin or --target aarch64-apple-darwin.

Apple ARM64 (aka Apple Silicon)

Due to inability to build the management interface proto files on ARM64 (see this issue) the Apple ARM64 build must be done in 2 stages:

  1. Build management interface proto files on a non-ARM64 platform
  2. Use the built proto files during the main build by setting the MANAGEMENT_INTERFACE_PROTO_BUILD_DIR environment variable to the path the proto files

To build the management interface proto files there is a script (execute it on a non-ARM64 platform):

cd gui/scripts
npm ci

After that copy the files from gui/src/main/management_interface/ and gui/build/src/main/management_interface/ directories into a single directory on your Apple Silicon Mac, and set the value of MANAGEMENT_INTERFACE_PROTO_BUILD_DIR to that directory while running the main build.

Make sure that the version of Go on your Mac is 1.16 (the first version to add support for Apple Silicon) or newer.

Install protobuf by running:

brew install protobuf

When all is done run the main build. Assuming that you copied the proto files into /tmp/management_interface_proto directory, the build command will look as follows:

MANAGEMENT_INTERFACE_PROTO_BUILD_DIR=/tmp/management_interface_proto ./ --dev-build

If you want to build each component individually, or run in development mode, read the following sections.


Running the script will build the necessary Rust daemon for all supported ABIs and build the final APK:


You may pass a --dev-build to build the Rust daemon and the UI in debug mode and sign the APK with automatically generated debug keys:

./ --dev-build

If the above fails with an error related to compression, try allowing more memory to the JVM:

echo "org.gradle.jvmargs=-Xmx4608M" >> ~/.gradle/
./android/gradlew --stop

Building and running mullvad-daemon on desktop

  1. Firstly, on MacOS and Linux, one should source to set the default environment variables.

  2. On Windows, make sure to start bash first (e.g., Git BASH). Then build the C++ libraries:

     ./ --dev-build
  3. Build the system daemon plus the other Rust tools and programs:

    cargo build
  4. Copy the OpenVPN and Shadowsocks binaries, and our plugin for it, to the directory we will use as resource directory. If you want to use any other directory, you would need to copy even more files.

    cp dist-assets/binaries/<platform>/{openvpn, sslocal}[.exe] dist-assets/
    cp target/debug/*talpid_openvpn_plugin* dist-assets/
  5. On Windows, also copy wintun.dll to the build directory:

    cp dist-assets/binaries/x86_64-pc-windows-msvc/wintun.dll target/debug/
  6. On Windows, the daemon must be run as the SYSTEM user. You can use PsExec to launch an elevated bash instance before starting the daemon in it:

    psexec64 -i -s bash.exe
  7. Run the daemon with verbose logging (from the root directory of the project):

    sudo MULLVAD_RESOURCE_DIR="./dist-assets" ./target/debug/mullvad-daemon -vv

    Leave out sudo on Windows. The daemon must run as root since it modifies the firewall and sets up virtual network interfaces etc.

Environment variables controlling the execution

  • TALPID_FIREWALL_DEBUG - Helps debugging the firewall. Does different things depending on platform:

    • Linux: Set to "1" to add packet counters to all firewall rules.
    • macOS: Makes rules log the packets they match to the pflog0 interface.
      • Set to "all" to add logging to all rules.
      • Set to "pass" to add logging to rules allowing packets.
      • Set to "drop" to add logging to rules blocking packets.
  • TALPID_FIREWALL_DONT_SET_SRC_VALID_MARK - Forces the daemon to not set src_valid_mark config on Linux. The kernel config option is set because otherwise strict reverse path filtering may prevent relay traffic from reaching the daemon. If rp_filter is set to 1 on the interface that will be receiving relay traffic, and src_valid_mark is not set to 1, the daemon will not be able to receive relay traffic.

  • TALPID_DNS_MODULE - Allows changing the method that will be used for DNS configuration on Linux. By default this is automatically detected, but you can set it to one of the options below to choose a specific method:

    • "static-file": change the /etc/resolv.conf file directly
    • "resolvconf": use the resolvconf program
    • "systemd": use systemd's resolved service through DBus
    • "network-manager": use NetworkManager service through DBus
  • TALPID_FORCE_USERSPACE_WIREGUARD - Forces the daemon to use the userspace implementation of WireGuard on Linux.

  • TALPID_DNS_CACHE_POLICY - On Windows, this changes how DNS is configured:

    • 1: The default. This sets a global list of DNS servers that dnscache will use instead of the servers specified on each interface.
    • 0: Only set DNS servers on the tunnel interface. This will misbehave if local custom DNS servers are used.
  • TALPID_DISABLE_OFFLINE_MONITOR - Forces the daemon to always assume the host is online.

  • MULLVAD_MANAGEMENT_SOCKET_GROUP - On Linux and macOS, this restricts access to the management interface UDS socket to users in the specified group. This means that only users in that group can use the CLI and GUI. By default, everyone has access to the socket.

Setting environment variable

  • On Windows, one can use setx from an elevated shell, like so


    For the change to take effect, one must restart the daemon

    sc.exe stop mullvadvpn
    sc.exe start mullvadvpn
  • On Linux, one should edit the systemd unit file via systemctl edit mullvad-daemon.service and edit it like so


    For the change to take effect, one must restart the daemon

    sudo systemctl restart mullvad-daemon
  • On macOS, one can use launchctl like so

    sudo launchctl setenv TALPID_DISABLE_OFFLINE_MONITOR 1

    For the change to take effect, one must restart the daemon

    launchctl unload -w /Library/LaunchDaemons/net.mullvad.daemon.plist
    launchctl load -w /Library/LaunchDaemons/net.mullvad.daemon.plist

Building and running the desktop Electron GUI app

  1. Go to the gui directory

    cd gui
  2. Install all the JavaScript dependencies by running:

    npm install
  3. Start the GUI in development mode by running:

    npm run develop

If you change any javascript file while the development mode is running it will automatically transpile and reload the file so that the changes are visible almost immediately.

Please note that the GUI needs a running daemon to connect to in order to work. See Building and running mullvad-daemon for instruction on how to do that before starting the GUI.

Supported environment variables

  1. MULLVAD_PATH - Allows changing the path to the folder with the mullvad-problem-report tool when running in development mode. Defaults to: <repo>/target/debug/.

Making a release

When making a real release there are a couple of steps to follow. <VERSION> here will denote the version of the app you are going to release. For example 2018.3-beta1 or 2018.4.

  1. Follow the Install toolchains and dependencies steps if you have not already completed them.

  2. Make sure the is up to date and has all the changes present in this release. Also change the [Unreleased] header into [<VERSION>] - <DATE> and add a new [Unreleased] header at the top. Push this, get it reviewed and merged.

  3. Run ./ <VERSION>. This will do the following for you:

    1. Check if your repository is in a sane state and the given version has the correct format
    2. Update package.json with the new version and commit that
    3. Add a signed tag to the current commit with the release version in it

    Please verify that the script did the right thing before you push the commit and tag it created.

  4. When building for Windows or macOS, the following environment variables must be set:

    • CSC_LINK - The path to the certificate used for code signing.

      • Windows: A .pfx certificate.
      • macOS: A .p12 certificate file with the Apple application signing keys. This file must contain both the "Developer ID Application" and the "Developer ID Installer" certificates + private keys.
    • CSC_KEY_PASSWORD - The password to the file given in CSC_LINK. If this is not set then will prompt you for it. If you set it yourself, make sure to define it in such a way that it's not stored in your bash history:

      export HISTCONTROL=ignorespace
      export CSC_KEY_PASSWORD='my secret'
    • macOS only:

      • NOTARIZE_APPLE_ID - The AppleId to use when notarizing the app. Only needed on release builds

      • NOTARIZE_APPLE_ID_PASSWORD - The AppleId password for the account in NOTARIZE_APPLE_ID. Don't use the real AppleId password! Instead create an app specific password and add that to your keyring. See this documentation:


        1. Generate app specific password on Apple's AppleId management portal.
        2. Run security add-generic-password -a "<apple_id>" -w <app_specific_password> -s "something_something"
        3. Set NOTARIZE_APPLE_ID_PASSWORD="@keychain:something_something".
  5. Run ./ on each computer/platform where you want to create a release artifact. This will do the following for you:

    1. Update relays.json with the latest relays
    2. Compile and package the app into a distributable artifact for your platform.

    Please pay attention to the output at the end of the script and make sure the version it says it built matches what you want to release.

Running Integration Tests

The integration tests are located in the mullvad-tests crate. It uses a mock OpenVPN binary to test the mullvad-daemon. To run the tests, the mullvad-daemon binary must be built first. Afterwards, the tests should be executed with the integration-tests feature enabled. To simplify this procedure, the script can be used to run all integration tests.

Command line tools for Electron GUI app development

  • $ npm run develop - develop app with live-reload enabled
  • $ npm run lint - lint code
  • $ npm run pack:<OS> - prepare app for distribution for your platform. Where <OS> can be linux, mac or win
  • $ npm test - run tests

Tray icon on Linux

The requirements for displaying a tray icon varies between different desktop environments. If the tray icon doesn't appear, try installing one of these packages:

  • libappindicator3-1
  • libappindicator1
  • libappindicator

If you're using GNOME, try installing one of these GNOME Shell extensions:

  • TopIconsFix
  • TopIcons Plus

Repository structure

Electron GUI app and electron-builder packaging assets

  • gui/
    • assets/ - Graphical assets and stylesheets
    • src/
      • main/
        • index.ts - Entry file for the main process
      • renderer/
        • app.tsx - Entry file for the renderer process
        • routes.tsx - Routes configurator
        • transitions.ts - Transition rules between views
      • config.json - App color definitions and URLs to external resources
    • tasks/ - Gulp tasks used to build app and watch for changes during development
      • distribution.js - Configuration for electron-builder
    • test/ - Electron GUI tests
  • dist-assets/ - Icons, binaries and other files used when creating the distributables
    • binaries/ - Git submodule containing binaries bundled with the app. For example the statically linked OpenVPN binary. See the README in the submodule for details
    • linux/ - Scripts and configuration files for the deb and rpm artifacts
    • pkg-scripts/ - Scripts bundled with and executed by the macOS pkg installer
    • windows/ - Windows NSIS installer configuration and assets
    • ca.crt - The Mullvad relay server root CA. Bundled with the app and only OpenVPN relays signed by this CA are trusted

Building, testing and misc

  • - Compiles the C++ libraries needed on Windows
  • - Sanity checks the working directory state and then builds release artifacts for the app

Mullvad Daemon

The daemon is implemented in Rust and is implemented in several crates. The main, or top level, crate that builds the final daemon binary is mullvad-daemon which then depend on the others.

In general one can look at the daemon as split into two parts, the crates starting with talpid and the crates starting with mullvad. The talpid crates are supposed to be completely unrelated to Mullvad specific things. A talpid crate is not allowed to know anything about the API through which the daemon fetch Mullvad account details or download VPN server lists for example. The talpid components should be viewed as a generic VPN client with extra privacy and anonymity preserving features. The crates having mullvad in their name on the other hand make use of the talpid components to build a secure and Mullvad specific VPN client.

  • Cargo.toml - Main Rust workspace definition. See this file for which folders here are daemon Rust crates.
  • mullvad-daemon/ - Main Rust crate building the daemon binary.
  • talpid-core/ - Main crate of the VPN client implementation itself. Completely Mullvad agnostic privacy preserving VPN client library.


Explanations for some common words used in the documentation and code in this repository.

  • App - This entire product (everything in this repository) is the "Mullvad VPN App", or App for short.
    • Daemon - Refers to the mullvad-daemon Rust program. This headless program exposes a management interface that can be used to control the daemon
    • Frontend - Term used for any program or component that connects to the daemon management interface and allows a user to control the daemon.
      • GUI - The Electron + React program that is a graphical frontend for the Mullvad VPN App.
      • CLI - The Rust program named mullvad that is a terminal based frontend for the Mullvad VPN app.

File paths used by Mullvad VPN app

A list of file paths written to and read from by the various components of the Mullvad VPN app


On Windows, when a process runs as a system service the variable %LOCALAPPDATA% expands to C:\Windows\system32\config\systemprofile\AppData\Local.

All directory paths are defined in, and fetched from, the mullvad-paths crate.


The settings directory can be changed by setting the MULLVAD_SETTINGS_DIR environment variable.

Platform Path
Linux /etc/mullvad-vpn/
macOS /etc/mullvad-vpn/
Windows %LOCALAPPDATA%\Mullvad VPN\
Android /data/data/net.mullvad.mullvadvpn/


The log directory can be changed by setting the MULLVAD_LOG_DIR environment variable.

Platform Path
Linux /var/log/mullvad-vpn/ + systemd
macOS /var/log/mullvad-vpn/
Windows C:\ProgramData\Mullvad VPN\
Android /data/data/net.mullvad.mullvadvpn/


The cache directory can be changed by setting the MULLVAD_CACHE_DIR environment variable.

Platform Path
Linux /var/cache/mullvad-vpn/
macOS /Library/Caches/mullvad-vpn/
Windows C:\ProgramData\Mullvad VPN\cache
Android /data/data/net.mullvad.mullvadvpn/cache

RPC address file

The full path to the RPC address file can be changed by setting the MULLVAD_RPC_SOCKET_PATH environment variable.

Platform Path
Linux /var/run/mullvad-vpn
macOS /var/run/mullvad-vpn
Windows //./pipe/Mullvad VPN
Android /data/data/net.mullvad.mullvadvpn/rpc-socket


The GUI has a specific settings file that is configured for each user. The path is set in the gui/packages/desktop/main/gui-settings.ts file.

Platform Path
Linux $XDG_CONFIG_HOME/Mullvad VPN/gui_settings.json
macOS ~/Library/Application Support/Mullvad VPN/gui_settings.json
Windows %LOCALAPPDATA%\Mullvad VPN\gui_settings.json
Android Present in Android's logcat


Icons such as the logo and menubar icons are automatically generated. The source files are:

Path Usage
graphics/icon.svg The logo icon used for e.g. application icon and in app logo
graphics/icon-mono.svg The logo icon used for the android notification icon
graphics/icon-square.svg Logo icon used to generate the iOS application icon
gui/assets/images/*.svg Icons used to generate iOS icons and used in the desktop app
gui/assets/images/menubar icons/svg/*.svg The frames for the menubar icon

Generate desktop icon by running


Generate android icons


Generate iOS icon and assets

ios/convert-assets.rb --app-icon
ios/convert-assets.rb --import-desktop-assets
ios/convert-assets.rb --additional-assets

Generate desktop menubar icons


The menubar icons are described futher here.

Locales and translations

Instructions for how to handle locales and translations are found here.

For instructions specific to the Android app, see here.

Audits, pentests and external security reviews

Mullvad has used external pentesting companies to carry out security audits of this VPN app. Read more about them in the audits readme.


Copyright (C) 2021 Mullvad VPN AB

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

For the full license agreement, see the file

The source code for the iOS app is GPL-3 licensed like everything else in this repository. But the distributed app on the Apple App Store is not GPL licensed, it falls under the Apple App Store EULA.

  • 1. Windows service crate

    Checklist for a PR:

    • [ ] Describe the change in Only applicable if the change has any impact for a user.

    This is the first part of Windows Service support for mullvad-daemon. I imagine that we'll have a service binary that will start/stop mullvad-daemon and communicate with it via RPC. This part is a self-registration that allows to register Windows service or unregister it.

    Currently it's possible by running (with admin privileges):

    target\debug\mullvad-service.exe -install


    target\debug\mullvad-service.exe -remove

    The second part of my work will contain the main and service control function implementations that will allow to actually start/stop mullvad-daemon etc..

    This change is Reviewable

    Reviewed by pronebird at 2018-03-21 17:47
  • 2. Windows service integration

    Checklist for a PR:

    • [ ] Describe the change in Only applicable if the change has any impact for a user.

    Baby steps towards a complete windows service implementation of daemon.


    • [X] Self-installation (--register-service)
    • [X] Basic service lifecycle
    • [X] Clean up some CLI routine. Currently cli::get_app is public, need this for match
    • [X] Figure out if we should be accepting daemon configuration via service arguments.

    This change is Reviewable

    Reviewed by pronebird at 2018-04-19 17:36
  • 3. Xp login

    Could not find any reasonable solution for tests of the footer visibility when just animating it out of sight, does anyone have any suggestions?

    Also noted that the cursor moves to the end after writing in a selected area, but it seems to be that way now as well so i didn't change anything.

    Put a fix for not being able to use the placeholderTextColor, so this will change the placeholder text color on support as well, but now its according to design i zeplin!

    Checklist for a PR:

    • [ ] Describe the change in Only applicable if the change has any impact for a user.

    This change is Reviewable

    Reviewed by anderklander at 2018-02-27 19:19
  • 4. Windows firewall management

    I've essentially done 3 things:

    • Added wfp submodule.
    • added a for talpid-core that can build our windows firewall library.
    • added some FFI glue to use said library to manage the firewall.

    This change is Reviewable

    Reviewed by pinkisemils at 2018-04-03 17:57
  • 5. Adding a way to pass `--mssfix` parameter to OpenVPN's subprocess.

    I've added some minor changes to the daemon to support optionally passing an extra parameter to the openvpn client that would inform TCP sessions about what their maximum packet sizes should be. The 2 RPCs serve to both set and get the parameters value.

    Do tell me if I should also add this change to the changelog.

    I'm not entirely certain if the best thing to do here isn't going with a more generic way of setting custom arguments. I'm also not certain if validating the MTU size is done in the right place.

    This change is Reviewable

    Reviewed by pinkisemils at 2018-03-15 19:48
  • 6. Rpc manager

    If this PR is merged, PR #96 must be closed.

    This is an initial attempt at using an IP address to connect to the master API server. It stores the IP in a cache and re-uses it when possible. If the cache is empty, the IP is resolved and stored in the cache.

    This version creates some more helper types increasing the level of abstraction. I also wrote a different version that's simpler and touches slightly less code. I pushed both as PRs so everyone can take a look and see which option is better. It might be better to choose one first then do a more fine-grained review of the code to avoid duplicated effort (sorry about that). After an option is chosen, the other PR must be closed.

    Checklist for a PR:

    • [ ] Describe the change in Only applicable if the change has any impact for a user.

    This change is Reviewable

    Reviewed by jvff at 2018-03-16 16:28
  • 7. Windows: Override and enforce DNS settings

    This is work in progress.

    However, it would be great to get some feedback on the overall structure of the code, and the approach used.

    Some of the things that need to be fixed:

    • All the TODOs
    • Pass errorSink to monitoring thread
    • Move generic WMI code into libcommon
    • Serialize settings to be restored and send to windns client ** This will be done continuously from the monitoring thread
    • Implement shelling out to netsh for updating settings on adapters that are offline
    • Extend Reset function to accept serialized settings to be restored

    This change is Reviewable

    Reviewed by mvd-ows at 2018-05-28 10:38
  • 8. Add C++ code to manage metrics for network interfaces on Windows.

    This PR adds winroute which is a C++ project that ensures that a given network interface has the top metric amongst all other network interfaces. I've also improved and I've added some FFI code to call into winroute. The metrics are only set if the target intreface's metric isn't set to 1 already.

    This change is Reviewable

    Reviewed by pinkisemils at 2018-06-25 13:27
  • 9. Test RPC address file creation on daemon start-up

    This is an early attempt at implementing a test for the RPC address file creation. I originally wanted to test multiple-daemons to see if only the first one would keep running, but I thought it might be better to start with something simpler and gradually complicate it.

    Feedback and suggestions welcome. I wrote this as an integration test, but other ways of testing can be discussed.


    • [ ] Make it cross platform (currently Unix specific);
    • [ ] See if it's possible/desirable to test as administrator.

    Checklist for a PR:

    • [x] Describe the change in Only applicable if the change has any impact for a user. This is not visible to the user.

    This change is Reviewable

    Reviewed by jvff at 2018-03-08 01:05
  • 10. Android setup

    Setup to be able to test on android and moving some stuff to platform.js to be able to run it without importing electron.

    At the moment the android build will fail on the SupportPage for still using electon, so don't expect anything fancy.

    It would be very good if you could help me with testing logging and clipboard, since i dont have macOS and was not able to start the backend at the moment.

    Based on the quit-button-position branch to get style changes.

    Installation instruction draft:


    Follow the installation instructions for react-native. At the moment hot-loading android and desktop will not work at the same time (due to modules not found when using the app structure), content is copied from app/ to mobile/js/ when the run-android script is run. The andorid project can be either bundled in the apk or run with a packager server, settings for this is found in the build.gradle file in mobile/app/

    The setup-android script installs the node_modules for the mobile project. (or just yarn install in the mobile/ dir)

    yarn setup-android

    To run and start logging. Will run on connected physical device or started emulator.

    yarn run-android

    This change is Reviewable

    Reviewed by anderklander at 2018-01-09 08:27
  • 11. Xp transistions

    New transistion component!

    Need some help with the Flow issues, ping @pronebird

    No impact for end user so no update to changelog.

    Checklist for a PR:

    • [x] Describe the change in Only applicable if the change has any impact for a user.

    This change is Reviewable

    Reviewed by anderklander at 2018-02-16 13:10
  • 12. [Feature Request - Android] Filter by Provider on Server List

    Hello, please add the Filter by Provider feature that is available on Mullvad Desktop App to the Mullvad Android App.

    There are servers that have 10 Gbps on the country that I usually connect in, and I like it to cycle to each of the 10 Gbps servers instead of alternating between the 10 Gbps and 1 Gbps servers on the Android app for a more consistent connection experience.

    Reviewed by 8227846265 at 2022-05-22 00:22
  • 13. [Feature Request] Add manual selection of server provider to CLI commands

    This would be very useful to have for people like me who struggle with bad ISP routing to some servers. Instead of manually double checking which server belongs to which provider and specifying servers to connect (and servers sometimes go offline) to avoid routing issues, it would be great to have an additional option to specify server provider in addition to country/hostname. For example for multihop purposes it could looks something like this:

    mullvad relay set location nl 31173 (exit to a random NL server hosted by 31173)
    mullvad relay set tunnel wireguard --entry-location se sto (entry via random SE-STO server)
    mullvad relay set hostname se2-wireguard (exit to SE2)
    mullvad relay set tunnel wireguard --entry-location nl ams 31173 (entry via random NL-AMS server hosted by 31173)
    Reviewed by mikamidd at 2022-05-20 22:58
  • 14. Fix unused dependencies loaded in the Android service/tile DI graph

    Fixes an issue with a UI specific DI module being loaded for all processes, even though it's only meant for the UI/Activity process.

    Git checklist:

    • [x] Describe the change in under the [Unreleased] header.
    • [x] Check that commits follow the Mullvad coding guidelines

    This change is Reviewable

    Reviewed by albin-mullvad at 2022-05-20 12:43
  • 15. Integrate device API

    Describe what this PR changes. Why this is wanted. And, if needed, how it does it.

    Git checklist:

    • [x] Describe the change in under the [Unreleased] header.
    • [x] Check that commits follow the Mullvad coding guidelines
    • Adds new tunnel settings (v2) model and settings manager.
    • Switch tunnel manager to using Device & Accounts API.
    • Add migration from old tunnel settings (v1) to v2.
    • Obsolete old REST API methods.
    • Obsolete keychain classes in favour of using Security frameworks directly.
    • Switch to using throw-ing functions instead of Result to reduce friction associated with handling the Result type.
    • Obsolete AccountExpiry.

    This change is Reviewable

    Reviewed by pronebird at 2022-05-20 09:43
  • 16. Add Port 123 as a valid WireGuard port

    In the mullvad app please add port 123 as 53 and wireguard port doesn't work. It is a common port that usually works. It would be great if you add it along 53 and wireguard port. Please also add the ability to add the port in the wireguard configuration generator. Right now port 123 is not allowed on the site but I manually edited the file and its working fine.

    Reviewed by AAraonWPaul at 2022-05-18 20:38
  • 17. Improve architecture documentation

    I've added the diagrams used in the tour of the daemon in and filled out some of the empty sections and expanded upon the others.

    This change is Reviewable

    Reviewed by pinkisemils at 2022-05-18 14:40
Private payments for mobile devices.

MobileCoin Fog This is the README file for MobileCoin Fog. Note to Developers MobileCoin Fog is a prototype. Expect substantial changes before and aft

May 6, 2022
Private payments for mobile devices.
Private payments for mobile devices.

Testing your first payment Please see for instructions on participating in the TestNet! Sending your first payment Please see fo

May 20, 2022
An open source desktop wallet for nano and banano with end-to-end encrypted, on chain messaging using the dagchat protocol.
An open source desktop wallet for nano and banano with end-to-end encrypted, on chain messaging using the dagchat protocol.

An open source wallet with end-to-end encrypted, on chain messaging for nano and banano using the dagchat protocol.

May 3, 2022
An application for creating encrypted vaults for the GNOME desktop.
An application for creating encrypted vaults for the GNOME desktop.

Vaults An application for creating encrypted vaults for the GNOME desktop. It currently uses gocryptfs and CryFS for encryption. Please always keep a

Apr 28, 2022
NFT & Marketplace Contracts with royalties and fungible token support. Sample React app included.
NFT & Marketplace Contracts with royalties and fungible token support. Sample React app included.

NFT Market Reference Implementation A PoC backbone for NFT Marketplaces on NEAR Protocol. Reference Changelog Changelog Progress: basic purchase of NF

Apr 28, 2022
All the data an IC app needs to make seamless experiences, accessible directly on the IC. DAB is an open internet service for NFT, Token, Canister, and Dapp registries.
All the data an IC app needs to make seamless experiences, accessible directly on the IC. DAB is an open internet service for NFT, Token, Canister, and Dapp registries.

DAB ?? Overview An Internet Computer open internet service for data. All the data an IC app needs to make a seamless experience, accessible directly o

May 17, 2022
Enigma Core library. The domain: Trusted and Untrusted App in Rust.

Enigma Core library Service Master Develop CI Badge Pure Rust Enclave && Untrusted in Rust. Core is part of the Enigma node software stack. The Core c

May 9, 2022
Trustworthy encrypted command line authenticator app compatible with multiple backups.
Trustworthy encrypted command line authenticator app compatible with multiple backups.

cotp - command line totp authenticator I believe that security is of paramount importance, especially in this digital world. I created cotp because I

Apr 22, 2022
A simple frontend web app in the Rust framework.

Seed Quickstart Basic Rust-only template for your new Seed app. 1. Create a new project You can use cargo generate to use this template. $ cargo gener

Dec 24, 2021
Flashcards: A spaced repetition app designed around org files.

Flashcards Since it's easy to create notes in org-mode and difficult to create flashcards, this app tries to ease the process of making cards! For you

Apr 29, 2022
The fast, light, and robust client for the Ethereum mainnet.

OpenEthereum Fast and feature-rich multi-network Ethereum client. » Download the latest release « Table of Contents Description Technical Overview Bui

May 23, 2022
Rust client to Opensea's APIs and Ethereum smart contracts Rust bindings & CLI to the Opensea API and Contracts CLI Usage Run cargo r -- --help to get the top level help menu: opensea-cli 0.1.0 Choo

May 25, 2022
Simple template for building smart contract(Rust) and RPC Client(web3.js) on Solana (WIP) ⛏👷🚧⚠️
Simple template for building smart contract(Rust) and RPC Client(web3.js) on Solana (WIP) ⛏👷🚧⚠️

Solana BPF Boilerplate Simple template for building smart contract(Rust) and RPC Client(web3.js) on Solana This boilerplate provides the following. Si

Jan 30, 2022
Easily and securely share files from the command line. A fully featured Firefox Send client.

Notice: the default Send host is provided by @timvisee (info). Please consider to donate and help keep it running. ffsend Easily and securely share fi

May 26, 2022
The fast, light, and robust client for Ethereum-like networks.

The Fastest and most Advanced Ethereum Client. » Download the latest release « Table of Contents Description Technical Overview Building 3.1 Building

May 26, 2022
The Fastest and most Advanced Ethereum Client

The Fastest and most Advanced Ethereum Client. » Download the latest release « Table of Contents Description Technical Overview Building 3.1 Building

Feb 17, 2022
Coinbase pro client for Rust

Coinbase pro client for Rust Supports SYNC/ASYNC/Websocket-feed data support Features private and public API sync and async support websocket-feed sup

Apr 20, 2022
Rust Ethereum 2.0 Client
Rust Ethereum 2.0 Client

Lighthouse: Ethereum 2.0 An open-source Ethereum 2.0 client, written in Rust and maintained by Sigma Prime. Documentation Overview Lighthouse is: Read

May 20, 2022
Reference client for NEAR Protocol

Reference implementation of NEAR Protocol About NEAR NEAR's purpose is to enable community-driven innovation to benefit people around the world. To ac

May 24, 2022