Kicksecure ™ VM Build Documentation

Download Docs News Forums

Tools Upload file Special pages Recent changes Print Version Page meta What links here Related changes Page information

Page Read Edit History Move Protection Unwatch Watch Delete Purge

User Preferences Watchlist Contributions Logout Create account Login

Donate

Your support makes all the difference!

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!

Introduction

This page documents how to build Kicksecure ™ VM (Virtual Machine) images for VirtualBox (.ova) or KVM (.qcow2) "from source code".

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:

1. Host preparation.
2. Get Kicksecure ™ source code (which includes Kicksecure ™ build script).
3. Run Kicksecure ™ build script.
4. 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.

Due to digital software verification instructions and Software Signature Verification Usability Issues these instructions might look more complicated then they actually are.

Digital 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.

1. Host preparation.
2. Get Kicksecure ™ source code (which includes Kicksecure ™ build script).
3. Verify digital software signatures.
4. Run Kicksecure ™ build script
5. Done, build of Kicksecure ™ has been completed.

Host Preparation

Expand all Collapse all

Host Preparation Notices

• operating system: You need to build on Debian bullseye, such as Kicksecure ™ 16 or a Debian bullseye 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 user user. Do not use sudo to run derivative-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 ~/Kicksecure/derivative-maker --flavor whonix-gateway -- --build --target virtualbox and ~/Kicksecure/derivative-maker --flavor whonix-workstation -- --build --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/1120_prepare-build-machine

Host Preparation Steps

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.
• Other platforms: No special notice.

3. sudo setup:

Chose either Option A or Option B.

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 name user as an example. If the user is using a different Linux user account name such as myname 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 group sudo 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: 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 as myname 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 group sudo 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.

Choose Version

Version Numbers Choice Information

1. Common sense is required when choosing the right version number.

2. For example, the latest available git tag version number is not necessarily the most stable or suitable.

3. Follow the Kicksecure ™ News Blog as it might contain information.

4. This documentation will be using 16.0.9.8-stable as an example. Replace 16.0.9.8-stable with the actual version chosen for the build.

5. Git tags by convention:

• have one of the following appendixes stable, testers-only or developers-only version.
• For example:
  • 16.0.9.8-stable
  • 16.0.9.8-testers-only
  • 16.0.9.8-developers-only
• all represent the very same source code.

6. If there is only git tag 16.0.9.8-developers-only available but a stable release announcement has been published, then there is no need to wait for the creation of 16.0.9.8-stable since it actually has already been blessed stable, would contain the identical source code anyhow but just have a different git tag name.

Version Numbers Choice Instructions

1. Go to https://forums.kicksecure.com/c/news/ and look for the latest stable version number.

2. Compare with the stable version number mentioned in the wiki.

3. For example, if 16.0.9.8 has been announced in the forums and is available from the wiki, git tag 16.0.9.8-developers-only is avaialble but 16.0.9.8-stable is not, then 16.0.9.8-developers-only can be safely used.

Get the Signing Key

This step is recommended for better security, but is not strictly required. (See Trust)

Get Kicksecure ™ Signing Key.

Get the Source Code

FREE

Note: By proceeding, you acknowledge that you have read, understood and agreed to our Terms of Service and License Agreement.

Install git.

sudo apt update && sudo apt install git

Get the source code including git submodules.

Note: Replace 16.0.9.8-stable with the actual tag you want to build.

git clone --depth=1 --branch 16.0.9.8-stable --jobs=4 --recurse-submodules --shallow-submodules https://github.com/Kicksecure/derivative-maker.git

Change Directory

Get into Kicksecure 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

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.

git fetch

Verify the chosen tag to build. Replace with tag you want to build.

git verify-tag 16.0.9.8-stable

The output should look similar to this.

object 1844108109a5f2f8bddcf2257b9f3675be5cfb22

type commit tag 16.0.9.8 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]

Check the GPG signature timestamp makes sense. For example, if you previously saw a signature from 2020 and now see a signature from 2019, then this might be a targeted rollback (downgrade) or indefinite freeze attack.

The warning.

gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner.

Is explained on the Kicksecure ™ Signing Key page and can be safely ignored.

By convention, git tags should point to signed git commits. (forum discussion) It is advisable to verify the signature of the git commit as well (replace 16.0.9.8 with the actual git tag being verified).

git verify-commit 16.0.9.8-stable^{commit}

The output should look similar to this.

commit 5aa1c307c943be60e7d2bfa5727fa5ada3a79c4a

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

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 16.0.9.8-stable

Replace 16.0.9.8-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:

16.0.9.8-stable

Check if source folder is pristine.

git status

Should show nothing.

HEAD detached at 16.0.9.8-stable
nothing to commit, working tree clean

If it shows something else, do not continue.

Check Git

Check if you really got the version you want.

git describe

The output should show.

16.0.9.8-stable

Check if the source folder is pristine.

git status

The output should show nothing.

HEAD detached at 16.0.9.8-stable
nothing to commit, working tree clean

If it shows something else, do not continue.

VM Creation

Mandatory. The following build targets are available.

• --target virtualbox creates VirtualBox VMs.
• --target qcow2 creates .qcow2 images for KVM and QEMU.
• --target raw creates .raw images.
• --target root is for Physical Isolation Build Documentation.
• --target utm , preliminary support, tested on Mac M1 (--arch arm64) with QEMU.
• --target virtualbox , --target qcow2 , and --target raw can be combined to build multiple images at once.

Mandatory. Choose a flavor.

• --flavor kicksecure-gateway-cli
• --flavor kicksecure-gateway-xfce
• --flavor kicksecure-workstation-cli
• --flavor kicksecure-workstation-xfce

Optional. Choose a target CPU architecture.

• --arch amd64 default, best tested.
• --arch i386 is untested.
• --arch arm64
• Potentially others.

Optional. Enable Kicksecure ™ APT repository inside the images. See Trust. This is done for official Kicksecure ™ redistributeable builds.

--repo true

See also Optional Build Configuration.

Note: These instructions use VirtualBox as an example, assume you have the Kicksecure ™ source code in your home folder (~/derivative-maker).

---

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!

~/Kicksecure/derivative-maker --flavor kicksecure-gateway-xfce --target virtualbox --clean

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!

~/Kicksecure/derivative-maker --flavor kicksecure-workstation-xfce --target virtualbox --clean

---

Build a Kicksecure ™ virtual machine image.

~/Kicksecure/derivative-maker --flavor kicksecure-gateway-xfce --target virtualbox --build

Build a Kicksecure ™ virtual machine image.

~/Kicksecure/derivative-maker --flavor kicksecure-workstation-xfce --target virtualbox --build

---

While building, you might see a few Expected Build Warnings.

VM Build Result

• 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 Kicksecure ™ and skip the rest of this page.

Unified Images

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 prepare_release script, OR
• B) Manually.
  • VirtualBox: Using the VirtualBox graphical or command line interface VM export feature could be used.
  • KVM: Manually.

Prepare Release

prepare_release is useful for:

• Creation of a unified .ova image or libvirt.xz archive
• Creation of torrent files.
• Creation of hash sum files.
• Creation of digital software signatures.
  • OpenPGP (gpg) signatures
  • signify signatures
• Adding the license agreement.
• Adding the disclaimer.
• Redistribution.
• Example: sudo -E /home/user/derivative-maker/packages/kicksecure/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

----

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.

Kicksecure ™ A secure by default operating system with the latest security research in place.

Donate

Follow us on social media

FREE  ·  PLUS  ·  PREMIUM Support

Dark mode

At Kicksecure we believe in freedom and trust. That's why we fully support Open Source and Freedom Software.

Kicksecure ™ is supported by Evolution Host DDoS Protected VPS.

The personal opinions of moderators or contributors to the Kicksecure ™ project do not represent the project as a whole. By using this website, you acknowledge you have read, understood, and agree to be bound by these these agreements: Terms of Service , Privacy Policy , Cookie Policy , E-Sign Consent , DMCA , Imprint Kicksecure ENCRYPTED SUPPORT LP, 2023

Donate

Kicksecure is free from corporate interest by being user funded. Thank you so much!

Scan the QR code or use the wallet address below.