Whonix for arm64 / Raspberry Pi ( RPi )



Using the official package would certainly be the best option. Though I could not get it working when I tested it I’m going to take a look at it again.


I tested it again with the official package from buster and it looks like only minor changes to the current build scripts would be required. The only thing that would be missing in the package would be the apparmor stuff from the kernel command line which could be added manually as an intermediate solution. But I’ll also open an issue for that on rpi firmware github page. Apparmor should be enabled by default in Buster anyways. For some final build test I need the official package from buster in the Whonix repo. Either in the official one or maybe there is also some way to put it in the local repo while building. The one from stretch definitely does not work, when I manually install the one from buster it works fine, however.
There is maybe also an issue with the package then being present in both the debian and in the whonix repo. In the latter one the version should be higher so I guess apt would install that but I’m not 100% sure. Otherwise we can’t use it in Depends and maybe have to install it manually in the build script.

Edit: btw, the deb.torproject.org signing key is expired and needs to be updated as soon as a new one is out.



Can you upload the package from buster to the Whonix repo? afaik the repo is not used during the build but only the local one and debian repos. So we would need to add the online repo during the build and then install only this package from there. Alternatives would be to download it manually during the build and then install it with dpkg or use apt pinning and install it from buster, though we would need to add buster then to the sources.list.



Can do… But… Could you please add the code for doing that here https://github.com/Whonix/Whonix/blob/master/build-steps.d/1200_create-debian-packages?

This would require a new file here as well: https://github.com/Whonix/Whonix/tree/master/build_sources

Or could we add buster just here https://github.com/Whonix/Whonix/blob/master/build_sources/debian_stable_current_clearnet.list without screwing the build process by installing buster packages in stretch (Whonix 14) Non-Qubes-Whonix GUI builds? In theory should work. Would you mind comparing the build log for Non-Qubes-Whonix GUI builds?

(If that is working in theory also we could abolish https://github.com/Whonix/Whonix/blob/master/build_sources/debian_testing_current_clearnet.list etc and simplify the code.)

For redistributable builds doing that manually would be a quality regression. Any opinion? @HulaHoop


It would complicate the process and can harm the security of the build environment.


I’m going to give apt-pinning a try.

Is this even used during the build?


Yes, used.

mygrep -r build_sources

build-steps.d/1300_create-raw-image:   cp "$whonix_build_sources_list_primary" "/etc/debootstrap/etc/apt/sources.list"
build-steps.d/1100_prepare-build-machine:   cp "$whonix_build_sources_list_primary" "$cow_folder/etc/apt/sources.list"
build-steps.d/1100_prepare-build-machine:            true "INFO: Installing VirtualBox using $whonix_build_sources_list_primary..."
build-steps.d/1100_prepare-build-machine:               -o Dir::Etc::sourcelist="$whonix_build_sources_list_primary" \
build-steps.d/1100_prepare-build-machine:               -o Dir::Etc::sourcelist="$whonix_build_sources_list_primary" \
build-steps.d/1100_prepare-build-machine:            ## Get rid of $whonix_build_sources_list_primary package list, while keeping
build-steps.d/1200_create-debian-packages:   ## Update $whonix_build_sources_list_primary package list while keeping
build-steps.d/1200_create-debian-packages:      -o Dir::Etc::sourcelist="$whonix_build_sources_list_primary" \
build-steps.d/1200_create-debian-packages:   ## Download VirtualBox guest additions from $whonix_build_sources_list_primary.
build-steps.d/1200_create-debian-packages:         -o Dir::Etc::sourcelist="$whonix_build_sources_list_primary" \
build-steps.d/1200_create-debian-packages:         -o Dir::Etc::sourcelist="$whonix_build_sources_list_primary" \
build-steps.d/1200_create-debian-packages:               -o Dir::Etc::sourcelist="$whonix_build_sources_list_primary" \
build-steps.d/1200_create-debian-packages:   ## Get rid of $whonix_build_sources_list_primary package list, while keeping
buildconfig.d/30_apt_opts.conf:## Does not play well with onion build_sources.
buildconfig.d/30_dependencies.conf:## required for onion build_sources
buildconfig.d/30_apt_sources.conf:if [ "$whonix_build_sources_list_newer" = "" ]; then
buildconfig.d/30_apt_sources.conf:   if [ "$whonix_build_sources_clearnet_or_onion" = "clearnet" ]; then
buildconfig.d/30_apt_sources.conf:      whonix_build_sources_list_newer="$WHONIX_SOURCE_FOLDER/build_sources/debian_testing_current_clearnet.list"
buildconfig.d/30_apt_sources.conf:      whonix_build_sources_list_newer="$WHONIX_SOURCE_FOLDER/build_sources/debian_testing_current_onion.list"
buildconfig.d/30_apt_sources.conf:if [ "$whonix_build_sources_list_primary" = "" ]; then
buildconfig.d/30_apt_sources.conf:   if [ "$whonix_build_sources_clearnet_or_onion" = "clearnet" ]; then
buildconfig.d/30_apt_sources.conf:      whonix_build_sources_list_primary="$WHONIX_SOURCE_FOLDER/build_sources/debian_stable_current_clearnet.list"
buildconfig.d/30_apt_sources.conf:      whonix_build_sources_list_primary="$WHONIX_SOURCE_FOLDER/build_sources/debian_stable_current_onion.list"
buildconfig.d/30_apt_sources.conf:true "whonix_build_sources_list_primary      : $whonix_build_sources_list_primary"
buildconfig.d/30_apt_sources.conf:true "whonix_build_sources_list_newer        : $whonix_build_sources_list_newer"
buildconfig.d/30_apt_sources.conf:   temp_="$(grep --invert-match "#" "$whonix_build_sources_list_primary")"
buildconfig.d/30_apt_sources.conf:   temp_="$(grep --invert-match "#" "$whonix_build_sources_list_primary")"
buildconfig.d/30_apt_sources.conf:   temp_="$(grep --invert-match "#" "$whonix_build_sources_list_newer")"
help-steps/parse-cmd:                  whonix_build_sources_clearnet_or_onion="clearnet"
help-steps/parse-cmd:                  whonix_build_sources_clearnet_or_onion="onion"
help-steps/parse-cmd:               export whonix_build_sources_list_primary="build_sources/debian_testing_frozen.list"
help-steps/parse-cmd:   if [ "$whonix_build_sources_clearnet_or_onion" = "" ]; then
help-steps/parse-cmd:Defaulting whonix_build_sources_clearnet_or_onion to ${under}clearnet${eunder}.
help-steps/parse-cmd:      export whonix_build_sources_clearnet_or_onion="clearnet"                                                                                                           
help-steps/create-local-temp-apt-repo:   cp "$whonix_build_sources_list_primary" "$CHROOT_FOLDER/$WHONIX_SOURCES_LIST_TEMP_BUILD_FOLDER/build_sources.list"                                   
help-steps/create-local-temp-apt-repo:   cat "$CHROOT_FOLDER/$WHONIX_SOURCES_LIST_TEMP_BUILD_FOLDER/build_sources.list"                                                                       
help-steps/remove-local-temp-apt-repo:   rm --force "$CHROOT_FOLDER/$WHONIX_SOURCES_LIST_TEMP_BUILD_FOLDER/build_sources.list"


I made a test with apt-pinning and it just installed only the raspi3-firmware package from buster and the rest from stretch. Going to do some more tests, though. We could maybe also just enable the apt-pinning for the rpi-gateway so it won’t get used for the other builds.


We could maybe also just enable the apt-pinning for the rpi-gateway so it won’t get used for the other builds.


As per https://lists.debian.org/debian-derivatives/2013/08/msg00005.html and https://lists.debian.org/debian-derivatives/2013/08/msg00006.html APT pinning can break in very bad ways.

And offend Debian.

(And don’t forget all the hate you will get from me and other deity@l.d.o inhabitants because your users end up reporting bugs about APT)

Our past APT pinning instructions lead to breaking the system. ( Templates incorrectly think they're not connected to a Whonix gateway. )


  • less code for download / reupload RPI firmware package
  • less maintenance work for me for download / reupload RPI firmware package


  • quality regression
  • offending Debian
  • possible issues on release upgrade
  • other possible issues due to APT pinning (no specific example, hard to foresee)

I am inclined to say yes to APT pinning.

Any opinion @HulaHoop?

How would that technically work? Shipping file /etc/apt/sources.list.d/rpi.list as well as /etc/apt/preferences.d/ in some package?

deb http://http.debian.net/debian stretch-backports main contrib non-free
deb tor+http://vwakviie2ienjx6t.onion/debian stretch-backports main contrib non-free

(Plus comments.)

And then include instructions to remove that file before release upgrade of Whonix when upgrading to Debian 10 / buster in Whonix release upgrade instructions?


imo, the reason for this was that each package got upgraded. Not just the desired one.

Disadvantages for building from source are: currently does not work due to being an architecture specific package, while the rest of the packages is not. Lots of lintian errors which I think are also due to being architecture specific.

Currently it is implemented via copying the build_sources_testing.list and preferences file to the build folder during the create-local-temp-apt-repo step. They can also be removed later on.
The firmware package currently depends only on dosfstools, though no specific version. Therefore, currently only raspi3-firmware is installed from buster and nothing else. Since the sources.list in the final version also does not contain anything from buster I would not expect any breakage from updates. The package should be more or less fixed at that version until Whonix gets updated to buster. To admit, the last part is more or less theory.


apt-pinning done properly is safe enough. I’ve been running my host with it enabled before upgrading to Stretch without any problems and never had to remove packages before the upgrade. Everything updated seamlessly enough.

It would benefit it us in other cases besides RPi builds too.

The most important thing is to find and apply accurate and updated documentation about pinning priority so things don’t unexpectedly start pulling in more deps and wreaking havoc. I think the important thing is to advise users to keep their hands off and not add more programs if they don’t know what they are doing and not doing so voids our “support”.


Merged. Minor commit on top.


That was quick :slight_smile:
Currently the network and date still has to be set manually. You likely also need to use a serial console. At least I could not yet get it working with HDMI. Either the reason is my hardware or something else during early boot like firmware or kernel. I’m going to make a test with a newer kernel and see if it helps. I’ll maybe also remove the wifi packages and make them Recommends instead of Depends. I think also a network config package specific to the cli versions would be required which sets eth0 to dhcp and the MAC to e.g. the one used for the gateway on Virtualbox.


I added the backports kernel as Depends for the rpi-gw metapackage. With this there is also HDMI output.





I hope you’ll like the clean rename of all packages with appendix -cli / -gui / -kde in https://github.com/Whonix/anon-meta-packages/blob/master/debian/control.

Do you think you could add, and maintain --whonix-workstation-cli? The command line switch is already implemented but the meta package non-qubes-whonix-workstation-cli does not exist yet.


Yeah, I already saw them when my old build commands broke^^
The build script, however, reminded me of the new flavors :wink:

I’d carefully say yes. The question is what the usecase would be, how this should look like and which applications should be in there. If we would remove everything gui specific it would be mostly Debian + a bit of Whonix specific network config/hardening


Due to KDE resource hunger and upcoming spectre/meltdown defenses security penalty, I am also considering to developing/introducing XFCE flavors.

I’d carefully say yes.


The question is what the usecase would be,

  • I am not sure. (What an answer.) It’s an experiment. A shoot into the blue. Just like there was no way to know there would be interest in Whonix generally.
  • Onion Services.
  • Development base for other desktop environments.

how this should look like and which applications should be in there.

  • Similar to Whonix-Gateway CLI.
  • No packages ending with -gui.

If we would remove everything gui specific it would be mostly Debian + a bit of Whonix specific network config/hardening



Some people recently claimed in some benchmarking thread on the linux reddit that KDE now consumes less resources. Afaik even less than XFCE. Same happened back then on github qubes-issues when qubes introduced XFCE. So it would be maybe a good idea to do some benchmarking first, in particular for stuff from buster which is not that far away and would be the likeliest target for a new desktop environment.