Verify a build

Vex generates and holds keys on your machine, so the single most valuable thing an attacker could give you is a modified build. Verifying what you run is therefore the first security step, before the wizard, before a wallet exists.

Signing coverage is not uniform across platforms, and this page says exactly where it is and is not.

What is signed, per OS

The release pipeline fails closed rather than shipping something unverified. On macOS it refuses to run without the signing and notarization credentials, then validates that notarization actually stapled to each .app bundle and that the embedded vex-mcp bridge (the Go binary behind Vex Studio) carries its own valid signature. On Windows it checks every produced .exe for a valid Authenticode signature, the expected publisher, and a timestamp.

Checking what you downloaded

On macOS, an unsigned or tampered build is refused by Gatekeeper. If a download tells you to bypass Gatekeeper, to right-click-open around it, or to run xattr to strip the quarantine flag, treat that as the warning it is: a real release does not need any of it. You can run the same check the pipeline runs:

spctl -a -vvv -t exec /Applications/Vex.app

On Windows, confirm the installer’s signature before running it, either in the file’s properties or from PowerShell. The signer should read VEX LABS PTE. LTD., the status should be Valid, and there should be a timestamp:

Get-AuthenticodeSignature .\Vex-*-win-x64.exe | Format-List Status, SignerCertificate, TimeStamperCertificate

On Linux there is nothing to check: the AppImage and the .deb carry no signature, so no local command can tell a genuine artifact from a modified one. What you control there is the source. Take the file only from the tagged release on GitHub Releases under Vex-Foundation/Vex, and expect the versioned artifact names the build produces, in the form Vex-<version>-linux-x64.AppImage. A file offered anywhere else, or under a different name, is not a build this documentation describes.

How updates reach you

The app updates through electron-updater against the GitHub provider, and it can only see published releases of the official repository. There is no private update server and no side channel that could hand your installation a different build. Nothing is downloaded or installed without you: the app checks in the background, and both the download and the restart that applies it are explicit actions.

• The pipeline builds, signs and notarizes on a tag push, so the artifacts you download and the artifacts the updater sees are the same ones.
• Signing happens inside the build, before the update manifests are written, because those manifests carry sha512 hashes of the finished artifacts. Signing afterwards would invalidate them and break updates for everyone.
• On Windows, electron-updater compares the publisher of a downloaded update against the pinned publisher name before installing it.
• Artifact names are versioned, which is what keeps differential downloads and the updater’s on-disk cache correct across releases.

Updater and signing integrity are in security scope. See the security model, and the disclosure process if you find a way to subvert either.

Official channels only

Anything else, a mirror, a “faster” download, a build attached in a chat, an installer sent by someone helpful in your DMs, is out of scope and should be assumed hostile. See Install for the normal path.