Whonix ™ VM Build Documentation
Introduction[edit]
This page documents how to build Whonix ™ VM (Virtual Machine) images for VirtualBox (.ova) or KVM (.qcow2) "from source code".
For Qubes-Whonix ™, see Qubes-Whonix ™ Build Documentation.
Building from source code as security advantages (see Trust).
The goal of this build documentation is to be usable by as many users as possible. Therefore written as easy as possible with no prior knowledge of tools used required.
The high level summary is:
- Host preparation.
- Get Whonix ™ source code (which includes Whonix ™ build script).
- Run Whonix ™ build script.
- Done, build of Whonix ™ has been completed.
Advanced users that already know how to use git
and how to perform digital software verification using OpenPGP (gpg
) do not need to strictly follow this documentation. See footnote(s) for details. [1]
Due to digital software verification instructions and Software Signature Verification Usability Issues these instructions might look more complicated then they actually are.
Digital software signatures can increase security but this requires knowledge. Learn more about digital software signature verification.
Steps concerning digital software verification are pointed out as "This step is recommended for better security, but is not strictly required. (See Trust.)"
When verifying digital software signatures, these instructions will be slightly more complicated but therefore even more secure.
- Host preparation.
- Get Whonix ™ source code (which includes Whonix ™ build script).
- Verify digital software signatures.
- Run Whonix ™ build script
- Done, build of Whonix ™ has been completed.
Host Preparation[edit]
- You need to build on Debian
bullseye
, such as Whonix-Workstation ™16
or a Debianbullseye
VM. - You need ~
30
GB free disk space. - You need ~
4
GB free RAM.- Might actually work with a lot less RAM.
- Might actually work with less RAM if you have swap.
- Do not build under user
root
. Login regular as useruser
and then usesudo
as documented below. - You cannot build on Whonix-Gateway ™ (due to networking issues).
- Build logs: If using a GUI (graphical user interface) it is recommended to set your terminal (for example
xfce4-terminal
) to unlimited scrollback, so you can watch the full build log and share it for support in case there are issues. - Short: Do not add private files to Whonix ™ source code folder! [...]
Long: [...] Unless you know what you are doing. Technically, it would work. This is recommended against. Those files would get managed by the respective package. When you later update Whonix ™ debian packages, your files would get deleted by the package manager. Also adding private files to Whonix ™ source code folder, later contributing to Whonix ™ development and accidentally pushing the wrong git branch would be a disaster. Better add your private files to Whonix ™ after building Whonix ™. Or add a custom build step adding your files, which then get copied from a folder outside of Whonix ™ source folder. See "Source Code Changes" in "Optional Build Configuration" below.
- Short: Make sure there aren't any VMs in VirtualBox (inside your build machine) already called Whonix-Gateway ™ or Whonix-Workstation ™!
Long: Because the build script would fail, because it tries to create VMs either named Whonix-Gateway ™ or Whonix-Workstation ™. Running the clean script between builds will prevent this error.
- Short: Do not try to build Whonix-Gateway ™ and Whonix-Workstation ™ at the same time!
Long: Building Whonix-Gateway ™ and Whonix-Workstation ™ at the same time is not supported due to limitations in the build script. In other words, do not try to run for example sudo ~/Whonix/whonix_build --flavor whonix-gateway -- --build --target virtualbox and sudo ~/Whonix/whonix_build --flavor whonix-workstation -- --build --target virtualbox at the same time. The build would probably fail.
- Short: Do not use images created inside Continuous Integration (CI) environments for anything besides testing!
Usually you are not using CI environments without knowing.
You can find out if you are running inside a CI environment by running.
If it shows nothing, i.e.
Everything is fine.
Otherwise, if it were to show.
true
Then do not use these images for anything besides testing.
Reason:
https://github.com/Whonix/Whonix/blob/master/build-steps.d/1100_prepare-build-machine#L577
- Install build dependencies and get the source code.
Update the package lists.
Install build dependencies.
- VirtualBox builds only: Install VirtualBox on the build machine as per recommended VirtualBox version. [2]
Choose Version[edit]
Common sense is required when choosing the right version number. For example, the latest available version number is not necessarily the most stable or suitable. Follow the Whonix ™ News Blog as it might contain information.
This documentation will be using 16.0.4.2-stable
as an example. Replace 16.0.4.2-stable
with the actual version chosen for the build.
Git tags by convention:
- have one of the following appendixes
stable
,testers-only
ordevelopers-only
version. - For example:
16.0.4.2-stable
16.0.4.2-testers-only
16.0.4.2-developers-only
- all represent the very same source code. [3]
If there is only git tag 16.0.4.2-developers-only
available but a stable release announcement has been published, then there is no need to wait for the creation of 16.0.4.2-stable
since it actually has already been blessed stable, would contain the identical source code anyhow but just have a different git tag name.
Get the Signing Key[edit]
This step is recommended for better security, but is not strictly required. (See Trust.)
Get the Whonix ™ Signing Key.
Get the Source Code[edit]
Note: By proceeding, you acknowledge that you have read, understood and agreed to our Terms of Service and License Agreement.
Install git.
Temporarily download using git isn't possible since Whonix source code is under a major restructuring. [4] Meanwhile the latest stable source code version can be downloaded as a tar xz file.
Note: This downloads 16.0.4.2-stable
. Download link: Whonix.tar.xz
Change Directory[edit]
Get into Whonix
source code folder because later on package build commands using ./whonix_build
are expected to be run from the root of the source folder.
OpenPGP Verify the Source Code[edit]
This chapter is recommended for better security, but is not strictly required. [5]
Git fetch. [6]
Verify the chosen tag to build. Replace with tag you want to build.
Note: Replace 16.0.4.2-stable
with the actual tag you want to build.
The output should look similar to this.
type commit tag 16.0.4.2 tagger Patrick Schleizer <adrelanos@whonix.org> 1392320095 +0000
. gpg: Signature made Thu 13 Feb 2014 07:34:55 PM UTC using RSA key ID 77BB3C48
gpg: Good signature from "Patrick Schleizer <adrelanos@whonix.org>" [ultimate] Check the GPG signature timestamp makes sense. For example, if you previously saw a signature from 2021 and now see a signature from 2020, then this might be a targeted rollback (downgrade) or indefinite freeze attack. [7]
This output might be followed by a warning as follows.
gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner.
The above gpg: WARNING
can be ignored since it does not alter the validity of the signature related to the downloaded key. Rather, this warning refers to the level of trust placed in the developers signing key and the web of trust. To remove this warning, the developers signing key must be personally signed with your own key.
By convention, git tags should point to signed git commits. [8] (forum discussion) It is advisable to verify the signature of the git commit as well (replace
16.0.4.2
with the actual git tag being verified).
The output should look similar to this.
gpg: Signature made Sun 07 Dec 2014 01:22:22 AM UTC using RSA key ID 77BB3C48 gpg: Good signature from "Patrick Schleizer <adrelanos@whonix.org>" [ultimate] Author: Patrick Schleizer <adrelanos@whonix.org> Date: Sun Dec 7 01:22:22 2014 +0000
.Checkout Version[edit]
Retrieve a list of available git tags.
Use git checkout to select the preferred version to build.
Note: Replace 16.0.4.2-stable
with the actual tag you want to build.
Check Git[edit]
Check if you really got the version you want.
The output should show.
Check if the source folder is pristine.
The output should show nothing.
nothing to commit, working tree clean
If it shows something else, do not continue.
VM Creation[edit]
1. Build target selection.
Mandatory The following build targets are available.
Probably only useful for developers. Choose a --target
. Either option A), B), C) or D). [9] [10]
Option | Build Target | Comment | Image Type | Target Parameter |
---|---|---|---|---|
A) | VirtualBox VMs | Production. | .vdi
|
--target virtualbox
|
B) | KVM (and QEMU) | KVM: Production.; QEMU: unsupported | .qcow2
|
--target qcow2
|
C) | raw images | Mostly interesting for developers / porters. | .raw
|
--target raw
|
D) | UTM with QEMU [11] | Tested on Mac M1, testers only, --arch arm64 .
|
.raw
|
--target utm
|
2. Flavor selection.
Mandatory. Choose a flavor.
Option | Flavor Name | Flavor Parameter |
---|---|---|
A) | Whonix-Gateway ™ CLI | --flavor whonix-gateway-cli
|
B) | Whonix-Gateway ™ Xfce | --flavor whonix-gateway-xfce
|
C) | Whonix-Workstation ™ CLI | --flavor whonix-workstation-cli
|
D) | Whonix-Workstation ™ Xfce | --flavor whonix-workstation-xfce
|
3. CPU target architecture selection.
Mandatory. Choose a target CPU architecture.
Option | CPU Architecture Name | Comment | CPU Architecture Parameter |
---|---|---|---|
A) | Intel and AMD64 [12] | Default, best tested. | --arch amd64
|
B) | i386 | Untested. [13] | --arch i386
|
C) | ARM64 | --arch arm64
| |
D) | Others. | Potentially. | [14] |
4. Whonix ™ APT repository choice.
Optional. Enable Whonix ™ APT repository inside the images. [15] See Trust. This is done for official Whonix ™ redistributeable builds.
5. Optional configurations.
Optional See also Optional Build Configuration.
6. Notices.
- These instructions assume you have the Whonix ™ source code in your home folder (
~/Whonix
), and - use VirtualBox as an example.
7. Delete any existing Whonix-Gateway ™ virtual machine with the following command.
Warning: This will delete any virtual machine named Whonix-Gateway ™ from VirtualBox installed on your build machine!
8. Delete any existing Whonix-Workstation ™ virtual machine with the following command.
Warning: This will delete any virtual machine named Whonix-Workstation ™ from VirtualBox installed on your build machine!
9. Build a Whonix-Gateway ™ virtual machine image. build command:
10. Build a Whonix-Workstation ™ virtual machine image. build command:
While building, you might see a few Expected Build Warnings.
Build Logs[edit]
Optional.
Mostly useful in case of build issues where sharing the build log is necessary for support.
If using:
- A) GUI (graphical user interface): It is recommended to set your terminal (for example xfce4-terminal) to unlimited scrollback, so you can watch the full build log and share it for support in case there are issues.
- B) CLI (command line user interface): In case there are build issues, it is recommended to redirect the build log to a text file. To do that, for example >> ~/build-log 2>&1could be appended to the very end of the build command to redirect the build output to build log file
~/build-log
.- Note: when using that command there will be no output in the terminal until the build is completed. This is as per Linux default and unspecific to Whonix ™. The build might not complete. In that case, that command would hang forever. To see if the build is stuck, it would be possible to open the build log file with a text editor. In that case, the file would have to be re-opened or refreshed to with F5 key to see new build output appended to the build log file. Or by using for example tail -n 100 -f ~/build-log 2>&1
- Note: when using that command there will be no output in the terminal until the build is completed. This is as per Linux default and unspecific to Whonix ™. The build might not complete. In that case, that command would hang forever. To see if the build is stuck, it would be possible to open the build log file with a text editor. In that case, the file would have to be re-opened or refreshed to with F5 key to see new build output appended to the build log file. Or by using for example
VM Build Result[edit]
- VirtualBox: The newly created VMs can be seen in VirtualBox user interface and in the usual VirtualBox data folders.
- KVM, QEMU, raw images: The resulting
.qcow2
and/or.raw
images can be found in~/whonix_binary
folder.
Most users have completed the build process at this point, can start using Whonix ™ and skip the rest of this page.
Unified Images[edit]
Optional: Creation of (unified)
.ova
image(s) for Whonix ™ VirtualBox or libvirt.xz
archives for Whonix ™ KVM. This might only be interesting if the goal is Redistribution of images to third parties such as the public.
There are two options.
- A) Automated, a bit difficult (since it expects preexisting signing keys), using prepare_release script, OR
- B) Manually.
- VirtualBox: Using the VirtualBox graphical or command line interface VM export feature could be used. [16]
- KVM: Manually.
Prepare Release[edit]
prepare_release is useful for:
- Creation of a unified
.ova
image orlibvirt.xz
archive - Creation of torrent files.
- Creation of hash sum files.
- Creation of digital software signatures.
- Adding the license agreement.
- Adding the disclaimer.
- Redistribution.
- Example: sudo -E /home/user/Whonix/packages/whonix-developer-meta-files/release/prepare_release --build --target virtualbox --flavor whonix-workstation-xfce
For private builds, i.e. for builds which are not supposed to be redistributed to others, none of this is important. If any of this was important, it could also be done manually.
Footnotes[edit]
- ↑
For example, these instructions fetch only a specific git tag. If you know how to use git, you are of course free to
git clone
the whole repository and then usegit verify-tag
,git verify-commit
,git checkout --quiet
andgit
generally as per usual. The reason why more specific commands are being used on this page is to simplify the process for laymen, to make these instructions as fail-safe as possible. - ↑ Due to technical challenges, see VirtualBox Installation Challenges.
- ↑
git diff 16.0.4.2-stable 16.0.4.2-developers-only
- ↑ Kicksecure and Whonix source code is being split.
- ↑ See Trust.
- ↑ Optional. [...]
- ↑ As defined by TUF: Attacks and Weaknesses:
- ↑
Beginning from git tag
9.6
and above. - ↑
Multiple build targets at the same time are also possible.
--target virtualbox --target qcow2 --target raw
- ↑
Physical Isolation Build Documentation
--target root
- ↑
- ↑
amd64
might imply AMD only. This is wrong.amd64
means Intel and AMD.For technical reasons, in Debian (and in many other Linux / Freedom Software related places) both, Intel and AMD, is called
amd64
. This is common knowledge without controversy among technical people, in doubt see Wikipedia X86-64.
- ↑ 32-bit or 64-bit?
- ↑
- Build script parameter
--arch
results in setting theBUILD_TARGET_ARCH
build variable. If you inspect (grep
tip) the build scripts for the variable name you can see other architectures might work but are untested. - porting Whonix ™ to other platforms
- Build script parameter
- ↑
--repo true
will setexport build_remote_repo_enable="true"
which results in settingDERIVATIVE_APT_REPOSITORY_OPTS="--enable --codename $whonix_build_apt_stable_release" export DERIVATIVE_APT_REPOSITORY_OPTS
whonix_build_apt_stable_release
defaults tobullseye
and could optionally through a build configuration set tobullseye-proposed-updates
,bullseye-testers
orbullseye-developers
. - ↑
This is sane since important VM settings were already configured in https://github.com/Whonix/Whonix/blob/master/build-steps.d/2600_create-vbox-vm
.
prepare_release
VM export does nothing special/important for privately used builds.