VeraCrypt: a signed Windows driver, wxWidgets at build time, and byte-reproducible release artifacts

Windows will not load the driver without a digital signature

The first thing the Windows build guide tells you is a hard platform constraint rather than a build step. The 64-bit editions of Windows Vista and every later version of Windows do not let the VeraCrypt driver run without an appropriate digital signature, and in some cases, such as playback of HD DVD content, the 32-bit editions do not either. That is why every .sys file in the official binary packages carries a signature from the IDRIX certificate, issued by GlobalSign, and why each official .exe and .sys file ends with embedded signatures plus the full certificate chain, including authority certificates, the CA-MS cross-certificate, and the IDRIX certificate itself. The consequence for you is that a self-compiled Windows binary is not merely a different build, it is a binary the operating system may refuse to load. Anyone comparing their own output against official binaries is told to expect roughly 10 KiB of extra size on the official side purely from that embedded signature block.

Unset SOURCE_DATE_EPOCH means your build stamps a different timestamp

The release pipeline has a rule about time that catches people out. When SOURCE_DATE_EPOCH is not set, a build from a git checkout takes the HEAD commit timestamp, while a build from a release tarball takes the release date recorded in src/Common/Tcdefs.h at 00:00 UTC. The documented way to reproduce official release artifacts from a git checkout is therefore to set SOURCE_DATE_EPOCH explicitly, or to build from the tarball instead. Vendored VeraCrypt sources living in another git checkout are treated the same way and pick up that checkout's HEAD timestamp, which means a vendor who forgets the variable silently changes the output of every artifact they ship. The stated scope covers packages too: both the generated .deb and .rpm are reproducible, and remain so on older rpm releases that lack the SOURCE_DATE_EPOCH and _buildhost build macros. The practical consequence is that a naive two-build comparison will differ for reasons that have nothing to do with your compiler.

wxWidgets is either installed system-wide or built from source first

The Linux and Mac OS X build path hinges on one library, and the guide handles both cases explicitly. If you have no wxWidgets shared library installed, you configure a static copy for VeraCrypt and build it first:

$ make WXSTATIC=1 WX_ROOT=/usr/src/wxWidgets wxbuild

WX_ROOT has to point at the source tree of the wxWidgets library, and the output lands in the ./wxrelease/ directory. Then VeraCrypt itself builds with:

$ make

or, if there is still no shared library on the system, `make WXSTATIC=1`. A successful build puts the executable in the directory named Main. Alongside that GUI toolkit, the requirement list names GNU Make, a GNU C++ Compiler of 4.0 or compatible, pkg-config, FUSE library and header files, and PCSC-lite library and header files, with Apple Xcode or the Xcode command line tools on Mac OS X. The consequence is that wxWidgets 3.0 is not optional and not merely a header package: on a minimal machine you are building a toolkit before you build the encryptor.

NOGUI drops the window toolkit, and macOS drops the option entirely

By default the build produces a universal executable that supports both a graphical and a text user interface, with the text mode reached through the switch --text. A console-only executable, which requires no GUI library at all, is a separate configuration:

$ make NOGUI=1 WXSTATIC=1 WX_ROOT=/usr/src/wxWidgets wxbuild

$ make NOGUI=1 WXSTATIC=1

The parameter is accepted on the wxbuild step as well as the main build, so the toolkit-free path does not need wxWidgets installed either. One platform closes the door on this. On Mac OS X, building a console-only executable is not supported. That is a genuine limitation for anyone planning to ship a headless macOS binary, for example on a build machine, because the configuration that works on Linux is simply absent on that target and the guide offers no substitute path. The default universal binary remains available there, GUI and all.

The EFI bootloader in the tree is a prebuilt binary, not source

Full disk encryption has to boot before an operating system exists, and VeraCrypt's answer to that problem lives somewhere you are not editing. Pre-built EFI binaries sit under src\Boot\EFI inside the source archive. The actual source code of the VeraCrypt EFI Boot Loader is licensed separately under LGPL and is available at a different location, at github.com/veracrypt/VeraCrypt-DCS, and build instructions for it are in the file src\Boot\EFI\Readme.txt. The consequence is a split you have to plan around: the boot path you compile from this repository is a finished artifact that you accept as given, while any change to how it decrypts or hands off control means cloning a second project, working under a different license, and rebuilding what this tree consumes. For an integrator auditing a boot chain, the part that decides how a machine starts is exactly the part not present as code here.

sign.bat is written around one certificate authority and a 2013-era SDK

Turning a Windows build into a package involves two documented requirements and one assumption you will probably have to change. First an environment variable named WSDK81 has to point at the Windows SDK for Windows 8.1 installation directory. Second, to generate MSI packages, WiX Toolset v3.11 must be installed. The assumption lives in the batch file itself: the Signing folder contains sign.bat, which signs all VeraCrypt components using a code signing certificate already present in the certificate store and then builds the final setup and MSI package. That script assumes the certificate is issued by GlobalSign, which is the case for IDRIX's own certificate. If yours comes from another authority, the instruction is to put its intermediate certificates in the Signing folder and modify sign.bat accordingly. So reproducing anything close to an official Windows package means editing a build script, and pinning your toolchain to an SDK generation that predates the operating systems the driver must load on.

macOS and Arch ship through two unrelated packaging paths

The two documented package routes share nothing but the source tree. On Arch Linux you change into a packaging directory in the checkout and let makepkg do the work:

$ cd src/Build/Packaging/arch

$ makepkg -si

On Mac OS X the route is homebrew plus a shell script. Dependencies go in with `brew install pkg-config yasm wxwidgets`, the FUSE component with `brew install --cask macfuse packages`, and the build itself runs through the script in the tree:

$ export VC_OSX_SDK=13.0

$ brew install pkg-config yasm wxwidgets

$ brew install --cask macfuse packages

$ ./src/Build/build_veracrypt_macosx.sh -b

Passing -b produces a local development build; passing -p to the same script produces the package instead, and the built executable ends up in .src/Main, a different location from the plain make path that leaves the executable in Main. Under Mac OS X the latest installed SDK is used by default, and VC_OSX_SDK is the override when you need an older one. The cost of this split is that your packaging recipe, its dependency set, and its output path all change depending on which of the two targets you are building.

License.txt forbids a derived work from carrying the VeraCrypt name

The terms sit in a plain License.txt at the root of the archive, and the source may be used only if you accept and agree to them. The specific clause worth knowing before you plan a fork is a naming restriction: the license specifies, for example, that a derived work must not be called TrueCrypt or VeraCrypt. Repository metadata reflects the same reality by asserting no standard license identifier for the project, so nothing in the machine-readable metadata tells you what you are agreeing to. The consequence is practical for anyone shipping under the name. If you patch the source, port it, or embed it in a product, you cannot distribute the result under either of those two names,. Read License.txt before you fork, not after, because the terms apply to the whole archive, including the prebuilt EFI binaries.

Editorial conclusion

Use this tree when you intend to compile VeraCrypt yourself and can satisfy the exact toolchain each platform names, especially the Windows signing path, which is written around one specific certificate authority. Do not expect a portable build, a text-only macOS build, or bootloader source here. Before you start, decide whether you can accept the naming restriction in License.txt, pin the SDK and compiler versions named in the guides, and set SOURCE_DATE_EPOCH if byte-identical artifacts matter to you.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. veracrypt/VeraCrypt on GitHub