Whonix build script now optionally supports installing packages from Whonix remote repository rather than building packages locally

Development
#1

By adding

--remote-derivative-packages true

Whonix images will be build with packages from Whonix developers repository. No packages will be build locally.

This option is optional.
This option is opt-in.

This option is useful for me during development, during creation of developers-only test images. It saves a ton of time having to rebuild all packages again and rebuilding these packages over and over again for each build.

This option might be useful for other developers who work on aspects of the build which is not related to any contents of any packages.

Builds which will be redistributed to users (those announced in Whonix News Forums) will still be build from locally build packages to ensure consistency.

Using --remote-derivative-packages true Kicksecure XFCE images were build in around a half hour.

https://github.com/Whonix/Whonix/commit/5f7564d7b628d22868c08feae0a5610328cc187d

https://github.com/Whonix/Whonix/commit/17ea90d9e4ebd568af2e0fc9f421d4535803d696

https://github.com/Whonix/Whonix/commit/113cd77276f2f47255fc2e67f8557f8eaeaeedf4

https://github.com/Whonix/Whonix/commit/117977ee7298b42de82cd81ecc0e1714d0667eeb

https://github.com/Whonix/Whonix/commit/27817cafaf6c776c0f5cf8c75989fb3e12a049ac

https://github.com/Whonix/Whonix/commit/66d0d19c9a4a3ea94968938fafa6b8b146a62616

1 Like
Whonix VirtualBox 15.0.0.6.6 - Testers Wanted!
Whonix host operating system
cross building Kicksecure arm64 on Kicksecure amd64
Whonix KVM 15.0.0.6.6 - Testers' Release
Whonix on Mac M1 (ARM) - User Support (still unsupported at time of writing)
Derivative Maker Automated CI Builder
Whonix VirtualBox 15.0.0.6.6 - Point Release
#2

Wohoo! Awesome feature. I’m using this bad boy th next time. Now I’ll be more motivated to make a new release sooner than once every quarter.

1 Like
#3

That could lead to inconsistent results.

If package build time is discouraging, I could perhaps rather figure out how to only rebuild packages that require rebuild and not always rebuild all packages all the time. But sometimes all packages have some minor changes (packaging compat level bumps and whatnot) and require rebuild so I wouldn’t know if this would save a lot time in practice.

That state of Whonix developers (or any) repository is currently still a bit opaque. All files are there in the open, welcome to review. But there are no tools to simplify this process. There is no way to know at which version Whonix/Whonix git tag version the Whonix developers repository is. Therefore the build version number wouldn’t tell much.

For example at the moment by building Whonix/Whonix git tag 15.0.0.4.9-stable with --remote-derivative-packages true it would actually use Whonix/Whonix build script version 15.0.0.4.9-stable with packages from Whonix developers repository which are at 15.0.0.5.6-developers-only.

Latest git tag doesn’t necessarily match the state of Whonix developers repository.

Sometimes changes in the developers repository are badly breaking. As in, no easy upgrade path. (Let’s say for example permission bugs.) These bugs aren’t fixed (sometimes difficult or impossible) since they never get introduced for any non-developer and simply replaced by functional packages.

Qubes-Whonix is build from Whonix proposed-updates repository but this requires orchestration to know when the repository matches the expected git tag version.

#4

How easy would it be to switch the build process to use apt repo snapshots for builds like outlined on this Tails page?

https://tails.boum.org/contribute/APT_repository/time-based_snapshots/

@Patrick

1 Like
#5

Looks complex, daunting.

A simpler implementation maybe: Instead of suite buster-developers there could be an additional suite 15.0.0.5.8.

In other words, instead of using
https://deb.whonix.org/dists/buster-developers/
a could use for example
https://deb.whonix.org/dists/15.0.0.5.8

Patches welcome or perhaps some day.

Implementation:

1 Like