Whonix Linux Installer - Development Discussion

Oops. Not sure what I was thinking. But I would disagree with my former self now.

Maybe when the installer was new, I thought it’s more important to easily have debugging information prominently visible. But since the installer is very stable, that isn’t needed now.


Hm. Upon review, I don’t like using a pipe to point at the public key. I guess that was done to avoid writing to the filesystem? But since we have a folder in the user’s home folder anyhow, it seems OK to write the public key there before signify uses it?

Seems better? For verification, I would trust the more common use case (not using a pipe) more.

We probably weren’t writing logs to a file at that fime.

I will pipe the key to a file anyway, so I don’t see a difference.
Also a pipe is not more insecure than a file in this sense.

Doing the changes.

1 Like

Piping a public key to a file is a very simple process. I don’t see any relevant attack surface

(Excluding an already locally compromised system which wouln’t be a useful threat model because game over anyhow.)

Having signify read a public key from a file and then performing a complex process which has relevant attack surface (they file which is currently being verified might be malicious, attempting to exploit signify) is a different thing.

So in result, I’d prefer to have the public key in the local file system and then signify can use that and doesn’t need go through any presumably less popular, less tested, more complex (presumably higher attack surface) code paths involving pipes.

Changes pushed.

1 Like

Excellent changes!

log info "Signify output: $(cat)" 

Possible that this could hang forever if signify doesn’t produce any output?

Still not possible to run signify with log_run info because it is a pipe?

Currently, option A:

  signify -V -p "${signify_pub_file}" \
    -m "${signify_checksum_file}" | log info "Signify output: $(cat)" \
    || return 1

|| return 1 needed?

Potential alternative, option B:

log_run info signify -V -p "${signify_pub_file}" -m "${signify_checksum_file}"
  • Advantage: log_run info
  • Disadvantage: Doesn’t hide signify output.

If using log_run, we don’t have a way to capture the output so it’s shown only for loglevel info (and more verbose)?

Every command “hangs” on shellscript because it runs one at a time, so if signify hangs, the cat doesn’t matter.
Also no output is different than the signify command hanging. If it doesn’t produce output, it’s signify program upstream fault.

Possible but then it does what you said, shows output without hiding.

Needed only to get the right order of log messages and die inside check_integrity().

Possible, but it would be made with cat or read, so every command would “hang” according to your first point.

I don’t see the need actually to print log_run anymore, that was useful for debugging in the beginning, it doesn’t protect against anything, just a good to know that not many users will use.

If the verification is successful or not is the important part.

Also, the alternative chosen by you should also be applicable to the checksum verification, so this:

Would also not be hidden.

1 Like

Much worse issues… Now fixed. And added a few TODOs to the script itself.

New version uploaded everywhere (web, apt, bullseye, bookworm, all suites).

With the previous security bug that I hot fixed just now, I think more eyes on the verification command and their output seems worthwhile. Therefore log_run info seems better?

Using it now: Bitbucket

1 Like

Completed the todos.
Please see the latest changes for cleaning the todos and completing them.

1 Like

We can consider this a bug report:


Or I could say I have a feature request.

If the distribution is unsupported: have a dedicated function to error out such as unsupported_distribution_detected (or better name).

  - At this time, your Linux distribution is unsupported by the ${guest_pretty} Installer.
  - Alternative: Check if manual installation is supported refer to:

Excellent! All merged! :slight_smile:

Debian trixie (testing) support has been added just now.

Feel free to refactor/improve.

During development, I temporarily disabled building other distro suites (Debian stable etc.) for CI builds to save some CI time. Just must not forget to re-enable. (Done.)

How could we allow installation on Debian testing based derivatives (such as kali?)?

Or installation on derivatives generally?

Do you think you could add support for Fedora? Instructions don’t look terribly difficult.

  • We could get the gpg key using extrepo. (Similar to how the installer already gets the gpg key for the Kicksecure repository)
  • Line gpgkey=https://www.virtualbox.org/download/oracle_vbox.asc looks insecure.

Qubes Fedora template folder /etc/yum.repo.d folder shows a nicer use.


This seems more secure:


Interesting but possibly not the most secure way to do this:

sudo dnf config-manager --add-repo=https://download.virtualbox.org/virtualbox/rpm/fedora/virtualbox.repo


Fedora support has been implemented, thanks to @grass with help from @nyxnor (CI).

The updated installer has been uploaded just now.

As for Fedora, an alternative to the Oracle repository might be RPM Fusion.

RPM Fusion homepage:

RPM Fusion wiki page about VirtualBox:

RPM Fusion package search for VirtualBox:

RPM Fusion package VirtualBox:

RPM Fusion package VirtualBox-kmod:

But there might be issues with SecureBoot as the wiki page mentions or the wiki page might be outdated.

Please allow Kali host operating systems in the Kicksecure / Whonix Linux Installer for Linux.


The ban on discussing anonymous pentesting does not apply here. I see zero issues with Kicksecure or Whonix being installed on top of Kali. Unless I have forgotten my own argument, in that case please remind me, please allow Kali hosts in the installer.

The issue in above forum thread was that I wanted to avoid Whonix forums morphing into a script kiddy forum where people ask how to anonymize attack tools. That seemed not a fight, risk worth taking on top of Whonix.

A Kicksecure or Whonix VM on top of Kali doesn’t simplify any anonymous attacks because Whonix doesn’t have a feature to anonymize the traffic of the host operating system yet at time of writing and even if it had it still would not help making attack tools work over Tor. These tools would still have broken connectivity for reasons inherit to these tools (which I don’t want to elaborate on).