Build Configuration

Kicksecure ™

Download

On Computer USB Installation Debian morph to Kicksecure Windows (VM) Linux (VM) Mac (VM) VirtualBox (VM) KVM (VM) Qubes (VM) More options Source Code

About

Overview Features Why Open Source? Project Activities Contributors Mission & Vision

Docs

Documentation FAQ Troubleshooting

Community

Forums Forum Best Practices Contribute

Support

Self Support First Policy Search Engines, Docs and AI Support (Limited) Reporting Bugs Contact (Restricted)

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

Note: All of the following build configuration steps are optional.

Expand all Collapse all

Introduction

Usually the build configuration does not need to be changed. Kicksecure built from source code comes with safe defaults. Whonix's APT Repository will not be used.

The most interesting build configurations (Terminal-Only, NoDefaultApps etc.) are documented in the following chapters.

If you are interested, click on Expand on the right.

If build configurations were used earlier, it might be better to delete the build configuration folder. A few example filenames may have changed since the last build.

sudo rm -r /etc/buildconfig-dist.d

Alternatively, experts can manually examine the /etc/buildconfig-dist.d folder and change its contents to suit their preferences.

/etc/buildconfig-dist.d is a modular flexible .d style configuration folder.

Less popular build configurations are documented in the buildconfig.d folder and on the Dev/Source_Code_Intro#Build_Configuration page, but it is less user-friendly.

To avoid typos, it is best to copy and paste text when creating build configuration files. Take care that editors do not capitalize variable names which are supposed to be lower case during copy and paste procedures.

---

Platforms Choice

Advanced users can create 32-bit instead of 64-bit builds.

If you are interested, click on Expand on the right.

• Kicksecure 14 and above is 64-bit by default.

To build Kicksecure 14 32-bit, add the following build parameter.

--arch i386

• kFreeBSD is entirely untested and most likely needs additional work (see footnotes).

• Kicksecure for arm64 development discussion:
  

https://forums.whonix.org/t/whonix-for-arm64-raspberry-pi-rpi/723

• Generally speaking, 64-bit builds cannot be created if running a 32-bit host kernel. See footnotes.

---

Kicksecure APT Repository Template:Build Documentation Project APT Repository

---

APT Onion Build Sources Template:Build Documentation APT Onion Build Sources

---

Torified or Host APT Cache Template:Build Documentation apt-cache

---

VM Settings

Such as image size, RAM, filesystem, hostname and password.

If building VMs, settings such as image size, RAM, filesystem, hostname and password can be customized.

If you are interested, press on expand on the right side.

This is only relevant for VM builds.

Several examples are below. Values can be changed to suit user preferences.

VirtualBox's --vmsize option (virtual RAM).

--vmram 128

VirtualBox's --vram option (virtual video RAM).

--vram 12

grml-debootstrap's --vmsize option.

--vmsize 200G

grml-debootstrap's --filesystem option.

--file-system ext4

grml-debootstrap's --hostname option.

--hostname host

grml-debootstrap's --password option.

--os-password changeme

grml-debootstrap's --debopt option.

--debopt "--verbose"

---

Build Variables Changes

It is possible to add build configuration files snippets which can change build variables.

Build Configuration Folders:

You can drop configuration file either in:

1. buildconfig.d or in
2. /etc/buildconfig-dist.d
3. ../buildconfig.d folder.

Files should have the file extension .conf.

Method 2. is recommended for users.

1. Contains examples. It is more difficult to use. Rather use the following.
2. sudo mkdir --parents /etc/buildconfig-dist.d
3. When /home/user/Kicksecure is your Kicksecure source folder, you could use /home/user/buildconfig.d as your Kicksecure build configuration folder. It is easier to use, since you don't have to git commit your build config files.

Below is an example how to use method 2.

sudo mkdir /etc/buildconfig-dist.d

Open file /etc/buildconfig-dist.d/50_user.conf in an editor with root rights.

Kicksecure

See Open File with Root Rights for detailed instructions on why to use sudoedit for better security and how to use it.

Note: Mousepad (or the chosen text editor) must be closed before running the sudoedit command.

sudoedit /etc/buildconfig-dist.d/50_user.conf

Kicksecure for Qubes

NOTES:

• When using Kicksecure-Qubes, this needs to be done inside the Template.

sudoedit /etc/buildconfig-dist.d/50_user.conf

• After applying this change, shutdown the Template.
• All App Qubes based on the Template need to be restarted if they were already running.
• This is a general procedure required for Qubes and unspecific to Kicksecure for Qubes.

Others and Alternatives

• This is just an example. Other tools could achieve the same goal.
• If this example does not work for you or if you are not using Kicksecure, please refer to this link.

sudoedit /etc/buildconfig-dist.d/50_user.conf

Add. (Replace it with whatever build configuration variable you wish to set.)

Example 1.

export DERIVATIVE_APT_REPOSITORY_OPTS='--enable --repository stable'

Example 2.

export tbb_version=13.0.1

Save.

Done.

---

Skip Steps

Developers users can speed up the build and skip sanity tests.

If you are interested, click on Expand on the right.

--sanity-tests false

---

Source Code Changes

This is only required if changes were made to the derivative-maker source folder! In that case click on Expand on the right.

This is not required if only a customized build configuration was added to the /etc/buildconfig-dist.d.d folder.

If changes were made to the derivative-maker source code, it is the easiest to use the following build parameter.

--allow-uncommitted true

Or if not building from a git tag, it is the easiest to use the following build parameter.

--allow-untagged true

Otherwise, changes must be committed to git first, before creating a git tag.

---