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:
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?
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:
${url_version_domain}/wiki/VirtualBox
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.
Please allow Kali host operating systems in the Kicksecure / Whonix Linux Installer for Linux.
related:
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).
--virtualbox-only to test VirtualBox installer. That test should be very quick because it is run after the full Whonix installation.
--virtualbox-only --oracle-repo this might be a bit slower.
CI on Ubuntu latest:
2023-08-15T17:19:48.0572513Z usr/bin/installer-dist: line 878: url_version_domain: unbound variable
Gonna add a stopgap for that by defensibly initializing the domain name. Some help messages in some corner cases might be missing the domain name but that’s better than a unbound variable for now.
CI on Debian testing:
Version number changed to n/a. Gonna add a fix for that too.
