I can test the images from time to time. If it will be added to official downloads list I’d still add the “Advanced” and “Experimental” tag.
Also there would be easier ways for physical isolation on other system than the rpi i.e. by using the raw images and just burning those to disk as already described somewhere in this forum instead of going through a default debian installation + build from source.
I don’t know if it would be feasible to upload compressed raw images? They should work on most systems, however, there could be issues with ethernet or graphics drivers and uefi.
imho it would also be a good idea to reduce the default image sizes to maybe 8-16 GB or to make dedicated raw images for physical isolation of this size. Otherwise you will always have to burn a 100GB image which takes a while. Also physical isolation is an edge case and I’m not sure if anyone ever reaches the 100GB limit even on a virtual gateway. With a smaller size it can fit on the average USB or SSD, you can always resize the disk image if you need more space. I can try to add a script for such an image to the build steps.
Not for VirtualBox builds please because there it’s quite handy. VMs won’t use that much space but can grow until that amount of space. (Sparse images.)
For --target raw (we already have that), other defaults less than 100 GB are fine. (--target raw isn’t really used by anyone yet afaik.)
For --target root, other defaults less than 100 GB are fine as well.
Can 2550_shrink_raw use the same method to mount the raw image like 2350_zerofree-raw?
Is truncate --size=3500M "$binary_image_raw" required or does --vmsize 4G do the same? (Perhaps even vmsize 3500M already works?)
Could you please move the raw image compression to prepare_release? Reason:
Those who create the raw image for themselves only, don’t require compression?
Those who wish to redistribute images should prepare_release.
Zerofree overwrites free parts with zeros for better compression later on.
The 2550_shrink_raw script, however, shrinks the whole disk including the partition.
They could maybe be merged but then you have to create a raw backup image. The 2550_shrink_raw script currently does that though it is not strictly required. After merge you need to shrink and truncate the one of the images while converting the other image to qcow2 and vdi. Otherwise you would get a default disk size of ~ 4GB for the gateway VM.
2550_shrink_raw does not mount the disk.
If you would do a completely separate build of the images for physical isolation then this would certainly be an alternative. Result should be the same. I’m going to give it a try. With the 2550_shrink_raw script + the --phys switch you could build the images for physical isolation + the VM images in one step.
non-qubes-whonix-(gateway|workstation)-(cli|kde|xfce) is neither by name a VM specific or VM unspecific package. Due to majority Whonix use case it defaults to VM specific.
Not easy to perfect without a lot code duplication / more package maintenance.
For now non-qubes-vm-enhancements-cli gets installed by default even for physically isolated (RPi) builds since it’s a dependency of non-qubes-whonix-gateway-cli.
Maybe non-qubes-vm-enhancements-cli should become a weak recommended package? Similar to how build-steps.d/1700_install-packages handles virtualbox-guest-x11 / spice-vdagent? To keep it installed for users who already have it whonix-legacy/debian/whonix-legacy.preinst could use
apt-mark auto non-qubes-vm-enhancements-cli || true
Thank you for still having “dual build” (or how would we coin it) i.e. KVM and VirtualBox images at the same time in mind. This was always hacky having spice-vdaagent in VirtualBox. The above described weak recommended package is hacky.
In future, KVM builds will be created, signed an uploaded by HulaHoop. No more dual builds by me. (Due to increases build workload - Qubes-Whonix, Whonix CLI, Whonix XFCE, hardened debian, custom workstation, what not.) Therefore we might no longer need the dual build support since that wasn’t a clean way to start with. (Otherwise using dual builds these raw images would have both, VirtualBox guest addition as well as spice-vdagent, even though neither is needed there - could cause issues in some point in future.)
Would you like to build, sign and upload these raw images?
I guess it should not be too much of a difference except for maybe disk space usage.
I also tried the alternative with --vmsize 3500M. It works the same, expanding the disk size to fill the whole device is maybe a little bit easier with this approach.
I can take a look, but I’m not sure how well it would integrate with my build infrastructure. I guess in particular the upload will be very slow.
No, I don’t have any older images. You could try to build a (stretch) version with some 14.* git tag around the beginning of the year. I don’t know if it will buil though and it would be outdated obviously.
Doubtful. I already asked someone for help, nothing came out of this. At the least I’d need some new hardware for my security wellbeing /dedicated buildmachine and for testing (like rpi 3+) and maybe (maybe) some other “infrastructural” changes. Until then I’m limited mostly to theoretical “work”