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.
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.
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”.
That was quick
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.
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
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.
Yay!
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.
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.
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.
I haven’t found any mentions of this. Please provide.
What I did read though was that XFCE works better in low RAM
environments. KDE might be even faster than that but requires more RAM
for that. Since RAM is limited in Whonix, this would still point at
XFCE. Also KDE might have better rendering speed on real hardware, but
that again wouldn’t effect Whonix in VMs much.
It was horrible to change from Whonix-Gateway from 512 MB RAM → 768 MB
RAM; and Whonix-Workstation from 768 MB RAM to 1024 MB RAM.