Kicksecure VM Build Documentation
Instructions to build Kicksecure Virtual Machine Images from Source Code.
Introduction[edit]
This page documents how to build Kicksecure VM (Virtual Machine) images for VirtualBox (.ova) or KVM (.qcow2) "from source code". Most users do not build Kicksecure from source code but instead download Kicksecure.
For Kicksecure for Qubes, see Kicksecure for Qubes 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 derivative-maker source code.
- Run derivative-maker.
- Done, build of Kicksecure 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 signatures: A tool enhancing download security. Commonly used across the internet.
- Learn more: Curious? Learn more about digital software signatures.
- Optional: Digital signatures are optional. If you've never used them before, there might be no need to start now.
- No worries: New to digital software signatures? It's okay, no need to worry.
- Not a requirement: Not mandatory for using Kicksecure, but an extra security measure for advanced users.
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 Kicksecure source code (which includes Kicksecure build script).
- Verify digital software signatures.
- Run Kicksecure build script
- Done, build of Kicksecure has been completed.
Host Preparation[edit]
Host Preparation Notices[edit]
- operating system: You need to build on Debian
bookworm
, such as Kicksecure17
or a Debianbookworm
VM. - disk space: You need ~
30
GB free disk space. - RAM: You need ~
4
GB free RAM.- Might actually work with a lot less RAM.
- Might actually work with less RAM if you have swap.
- linux user account: Do not build under user
root
. Login regular as useruser
. Do not usesudo
to runderivative-maker
because this is handled by the build script. - build place notice: You cannot build on Kicksecure (due to networking issues).
- build logs: 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.
...
- private files in source code warning: Do not add private files to Kicksecure source code folder! [...]
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 Kicksecure debian packages, your files would get deleted by the package manager. Also adding private files to Kicksecure source code folder, later contributing to Kicksecure development and accidentally pushing the wrong git branch would be a disaster. Better add your private files to Kicksecure after building Kicksecure. Or add a custom build step adding your files, which then get copied from a folder outside of Kicksecure source folder. See "Source Code Changes" in "Optional Build Configuration" below.
- Exiting VMs name collision warning: Make sure there aren't any VMs in VirtualBox (inside your build machine) already called Kicksecure or Kicksecure!
Because the build script would fail, because it tries to create VMs either named Kicksecure or Kicksecure. Running the clean script between builds will prevent this error.
- Parallel builds unsupported warning: Do not try to build Kicksecure and Kicksecure at the same time!
Building Kicksecure and Kicksecure at the same time is not supported due to limitations in the build script. In other words, do not try to run for example ~/derivative-maker/derivative-maker --flavor whonix-gateway -- --target virtualbox and ~/derivative-maker/derivative-maker --flavor whonix-workstation -- --target virtualbox at the same time. The build would probably fail.
- CI warning: 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.
echo "$CI"
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/Kicksecure/derivative-maker/blob/master/build-steps.d/1200_prepare-build-machine
Host Preparation Steps[edit]
1. build dependencies:
Install build dependencies and get the source code.
Update the package lists.
sudo apt update
Install build dependencies.
sudo apt install git time curl apt-cacher-ng lsb-release fakeroot dpkg-dev fasttrack-archive-keyring
2. Platform specific notices:
- VirtualBox: Install VirtualBox on the build machine as per recommended VirtualBox version. [2]
- Other platforms: No special notice.
3. sudo setup:
Chose either Option A or Option B.
Option A: passwordless sudo
Option A: Set up passwordless sudo.
- Abstract task overview: Setup passwordless sudo for your Linux user account name.
- Detailed task overview: Setup sudo and add your current linux user account to the linux user group
sudo
. The following instructions use Linux user account nameuser
as an example. If the user is using a different Linux user account name such asmyname
then the commands below have to be adjusted accordingly. - Unspecific: Configuration of sudo is unspecific to Kicksecure.
- Kicksecure specific: When building inside Kicksecure, user
user
is already a member of groupsudo
by default. Therefore the following step "1." can be skipped. - Detailed steps:
1. Setup sudoers. Add the operating system user name to sudoers.
Become root.
su
Add the user account to the sudoer's group. Replace user with the actual operating system user name.
sudo adduser user sudo
Reboot so group changes take effect.
reboot
2. Configure user user
to be able to use sudo without a password.
echo '%sudo ALL=(ALL:ALL) NOPASSWD:ALL' | sudo EDITOR=tee visudo -f /etc/sudoers.d/dist-build-sudo-passwordless >/dev/null
3. Done.
The process of setting up passwordless sudo has been completed.
Option B: long sudo timeout
Option B: Set a longer sudo password timeout.
- Abstract task overview: Setup sudo with a longer timeout for your Linux user account name.
- Detailed task overview: Setup sudo and increase the sudo password timeout (four all Linux user accounts or all users). The following instructions use Linux user account name
user
as an example. If the user is using a different Linux user account name such asmyname
then the commands below have to be adjusted accordingly. - Unspecific: Configuration of sudo is unspecific to Kicksecure.
- Kicksecure specific: When building inside Kicksecure, user
user
is already a member of groupsudo
by default. Therefore the following step "1." can be skipped. - Detailed steps:
1. Setup sudoers. Add the operating system user name to sudoers.
Become root.
su
Add the user account to the sudoer's group. Replace user with the actual operating system user name.
sudo adduser user sudo
Reboot so group changes take effect.
reboot
2. Configure user user
to be able to use sudo without a password.
echo 'Defaults timestamp_timeout=30' | sudo EDITOR=tee visudo -f /etc/sudoers.d/dist-build-sudo-timeout >/dev/null
3. Done.
The process of setting up a longer sudo timeout has been completed.
Special Notice[edit]
There is currently no special notice.
Choose Version[edit]
Get the Signing Key[edit]
This step is recommended for better security, but is not strictly required. (See Trust)
Get the Source Code[edit]
Install git.
sudo apt update && sudo apt install git
Get the source code including git submodules. [4] [5]
Note: Replace 17.0.4.5-stable
with the actual tag you want to build.
git clone --depth=1 --branch 17.0.4.5-stable --jobs=4 --recurse-submodules --shallow-submodules https://github.com/Kicksecure/derivative-maker.git
Change Directory[edit]
Get into derivative-maker
source code folder because later on package build commands using ./derivative-maker
are expected to be run from the root of the source folder.
cd derivative-maker
OpenPGP Verify the Source Code[edit]
This chapter is recommended for better security, but is not strictly required. (See Trust.)
Change directly into source code folder.
cd derivative-maker
Git fetch. [6]
git fetch
Verify the chosen tag to build. Replace with tag you want to build.
git verify-tag 17.0.4.5-stable
The output should look similar to this.
type commit tag 17.0.4.5 tagger Patrick Schleizer <adrelanos@kicksecure.com> 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@kicksecure.com>" [ultimate]The warning.
Is explained on the Kicksecure Signing Key page and can be safely ignored.
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
17.0.4.5
with the actual git tag being verified).
git verify-commit 17.0.4.5-stable^{commit}
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@kicksecure.com>" [ultimate] Author: Patrick Schleizer <adrelanos@kicksecure.com> Date: Sun Dec 7 01:22:22 2014 +0000
.Checkout Version[edit]
Retrieve a list of available git tags.
git --no-pager tag
Use git checkout to select the preferred version to build.
git checkout --recurse-submodules 17.0.4.5-stable
Replace 17.0.4.5-stable
with the actual version chosen for the build: the stable, testers-only or developers version. 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 Kicksecure News Blog as it might contain information.
Check if you really got the version you want.
git describe
Should show:
17.0.4.5-stable
Check if source folder is pristine.
git status
Should show nothing.
HEAD detached at 17.0.4.5-stable
nothing to commit, working tree clean
If it shows something else, do not continue.
Check Git[edit]
Check if you really got the version you want.
git describe
The output should show.
Check if the source folder is pristine.
git status
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.
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.
--flavor kicksecure-cli
--flavor kicksecure-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 | Unsupported. [13] | --arch i386
|
C) | ARM64 | --arch arm64
| |
D) | Others. | Potentially. | [14] |
4. Kicksecure APT repository choice.
Optional. Enable Kicksecure APT repository inside the images. [15] See Trust. This is done for official Kicksecure redistributeable builds.
--repo true
5. Optional configurations.
Optional. See also Optional Build Configuration.
6. Notices.
- These instructions assume you have the Kicksecure source code in your home folder (
~/derivative-maker
), and - use VirtualBox as an example.
7. Delete any existing Kicksecure virtual machine with the following command.
Warning: This will delete any virtual machine named Kicksecure from VirtualBox installed on your build machine!
~/derivative-maker/derivative-delete --flavor kicksecure-xfce --target virtualbox
9. Build a Kicksecure virtual machine image. build command:
~/derivative-maker/derivative-maker --flavor kicksecure-xfce --target virtualbox --repo true
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>&1
could 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 Kicksecure. 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
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~/derivative-binary
folder.
Most users have completed the build process at this point, can start using Kicksecure and skip the rest of this page.
Unified Images[edit]
Optional.
Creation of (unified)
.ova
image(s) for Kicksecure VirtualBox or libvirt.xz
archives for Kicksecure 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 dm-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]
dm-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: dm-prepare-release --build --target virtualbox --flavor kicksecure-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 17.0.4.5-stable 17.0.4.5-developers-only
- ↑
Optional
git
parameters:--depth=1
: Used to speed up download.--branch 17.0.4.5-stable
Usability. Used to speed up download.--jobs=4
: Used to speed up download.--recurse-submodules --shallow-submodules
: Usability.
git
users are free to drop any of these optional parameters. - ↑ Alternatively, this can be achieved with the following commands in several steps. This is useful if network issues arise. git clone --depth=1 --branch 17.0.4.5-stable https://github.com/Kicksecure/derivative-maker.git cd derivative-maker git submodule update --init --recursive --progress --jobs=4
- ↑ 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
- ↑
- ↑
- ↑ 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 Kicksecure to other platforms
- Build script parameter
- ↑
--repo true
will setexport build_remote_repo_enable="true"
which results in settingDERIVATIVE_APT_REPOSITORY_OPTS="--enable --codename $derivative-maker_apt_stable_release" export DERIVATIVE_APT_REPOSITORY_OPTS
derivative-maker_apt_stable_release
defaults tobookworm
and could optionally through a build configuration set tobookworm-proposed-updates
,bookworm-testers
orbookworm-developers
. - ↑
This is sane since important VM settings were already configured in https://github.com/Kicksecure/derivative-maker/blob/master/build-steps.d/2600_create-vbox-vm
.
dm-prepare-release
VM export does nothing special/important for privately used builds.
Unfinished: This wiki is a work in progress. Please do not report broken links until this notice is removed, use Search Engines First and contribute improving this wiki.

We believe security software like Kicksecure needs to remain open source and independent. Would you help sustain and grow the project? Learn more about our 10 year success story and maybe DONATE!