An installation of Debian can be transformed into Whonix ™ or Kicksecure ™. Also known as proverbial "sudo apt install whonix". This is also called distro-morphing. ^[1]

The following meta packages:

non-qubes-whonix-gateway-cli
non-qubes-whonix-gateway-xfce
non-qubes-whonix-workstation-cli
non-qubes-whonix-workstation-xfce
kicksecure-cli
kicksecure-cli-vm
kicksecure-xfce
kicksecure-xfce-vm

can be installed on Debian as per instructions Whonix ™ Packages for Debian Hosts.

This is unsupported, not tested by any Whonix ™ contributors and might need some work. What's missing?

instructions
a contributor
testing

This is being used in the wild. ^[archive]

From Source Code[edit]

Above instructions use packages from Whonix ™ binary repository. Transforming Debian to Whonix ™ or Kicksecure ™ is also possible from a local APT repository, i.e. without touching Whonix ™ binary repository. If you want to install from source code, info and scripts for automation (package building, creating a local repository, installation) are available ^[2] ^[3] ^[4] but could use better documentation.

Forum Discussion[edit]

https://forums.whonix.org/t/sudo-apt-get-install-whonix-part-i-distro-morphing/2346 ^[archive]

Distro Morphing vs Builds[edit]

What is the difference between a build (image downloaded or created from source code) versus distro morphing installation method?

It is quite similar as it should be.

Advantages of builds are that these are "cleaner":

Have tighter control over the packages getting installed. Using Debian installer is kinda like a "wonder box" what packages get installed. Difficult to predict what packages will be installed without skills to understand Debian installer. When using builds one can see what packages will be installed by studying mostly 1 file + dependency packages.
More likely to get the same tested build that developers and users received.
More likely to really get the distribution. Distro morphing might fail due to user error and not get noticed by novice users.
Redistributable.
- No daemons where ever started inside the chroot. (Builds where created by mounting the image and chroot'ing into it while preventing daemons from starting.)
  - Start of daemons inside the image creates several persistent private user data files which must not be re-used by third parties such as the public. In other words, the public should not be using these private user data files as this would be insecure. Such private user data files are for example entropy seeds or Tor state files such as Tor entry guards.
  - Cleaning such files at the end of the creation of the image is not a reliable method either since that depends on what packages are installed by default which changes over time and what private data daemons create which also changes over time. There is no such list or research into that topic.
  - By creating a clean image, it used to be created twice and then compared to check what kinda of private data leaked into it.
- Fewer non-deterministic artifacts which would hinder accomplishment of the reproducible builds ^[archive] goal.
- Fewer superfluous packages. Build dependencies are only installed on the build machine. Not installed inside the build.