Update Kicksecure and Whonix builds for Qubes R4.3 to Kicksecure and Whonix 18

[ArrayBolt3]

How to file a helpful issue

The problem you're addressing (if any)

Kicksecure and Whonix 18 are intended to target Qubes OS R4.3, and ideally Whonix 18 should be shipped as part of the final R4.3 release. Right now though Whonix 17 is shipped as part of the R4.3 beta releases, and users who build a Kicksecure template using the default kicksecure.yml configuration in qubes-builderv2 will get Kicksecure 17.

The solution you'd like

This is mostly a tracking bug so that we can properly synchronize getting all of the pieces in place for Kicksecure and Whonix 18 template builds. The master branches of qubes-template-whonix and qubes-template-kicksecure will need to be updated to point to trixie repositories, but this is a bit of a problem because the Kicksecure and Whonix 17 build config for Qubes OS R4.2 points to the master branch of qubes-template-whonix. We can keep the original bookworm code in new bookworm branches, and qubes-builderv2 can be changed to point to the bookworm branch of qubes-template-whonix, but that will break template builds too if the bookworm branches don't exist already. Thus doing this version bump will require doing the following actions in order:

• Create bookworm branches of qubes-template-kicksecure and qubes-template-whonix
• Update qubes-os-r4.2.yml in qubes-builderv2 so that the template-whonix component points to the bookworm branch
• Push code for Kicksecure and Whonix 18 to the qubes-template-kicksecure and qubes-template-whonix master branches
• Update qubes-os-r4.3.yml in qubes-builderv2 to build whonix-gateway-18 and whonix-workstation-18 templates, using dist: trixie
• Update kicksecyre.yml in qubes-builder-v2 in the same way

We might also consider getting rid of the master branch entirely and just creating branches for each individual base distribution (bookworm, trixie, forky, etc.) going forward so that next time this happens, Kicksecure and Whonix can just make a new distribution branch and we can submit one PR to qubes-builderv2 to update everything.

The value to a user and who that user might be

Qubes R4.3 users will get supported, up-to-date Whonix templates and can install a supported, up-to-date Kicksecure template.

Completion criteria checklist

(This section is for developer use only. Please do not modify it.)

[marmarek]

Currently the builder config supports only a single version of template-whonix repository, so it's impossible to have a single config that would work for both Whonix 17 and Whonix 18 in with this approach.
Are there more changes than just s/bookworm/trixie/? If not, it should be easy enough to simply use $DIST_CODENAME instead of hardcoded bookworm or trixie, and then a single branch works for both.

But if there are more changes (too many to wrap parts under some if), then the above plan should work. It's not perfect to remove config for the old template before new one is stable, but also it's not end of the world.

[ArrayBolt3]

Currently the builder config supports only a single version of template-whonix repository, so it's impossible to have a single config that would work for both Whonix 17 and Whonix 18 in with this approach.

A single config, yes, but are there not separate R4.2 and R4.3 configs?

Are there more changes than just s/bookworm/trixie/? If not, it should be easy enough to simply use $DIST_CODENAME instead of hardcoded bookworm or trixie, and then a single branch works for both.

There may not be right now, but I find it easy to imagine there could be in the future.

[marmarek]

A single config, yes, but are there not separate R4.2 and R4.3 configs?

Yes, R4.2 and R4.3 are separate. But technically Whonix 17 is still the latest stable version, no? And even if it isn't an issue at this moment (is it?), binding single Whonix version to a Qubes release will for example prevent doing test builds for upcoming release while retaining ability to do stable builds (not even official ones - it will also complicate local builds too - you'd need to shuffle correct configs around to not end up with for example Whonix 18 build but based on bookworm). But as I said above - if you prefer this way knowing the limitation, I'm okay with that.

There may not be right now, but I find it easy to imagine there could be in the future.

FWIW we have version-specific parts in a common builder-debian like this: https://github.com/QubesOS/qubes-builder-debian/blob/main/template_debian/distribution.sh#L314-L319

[ArrayBolt3]

binding single Whonix version to a Qubes release will for example prevent doing test builds for upcoming release while retaining ability to do stable builds (not even official ones - it will also complicate local builds too - you'd need to shuffle correct configs around to not end up with for example Whonix 18 build but based on bookworm).

Hmm, that's a valid point. At least in this specific instance though I think that's fine since Whonix 18 will not be made available for Qubes R4.2 (to my awareness), and Whonix 17 won't be supported on Qubes R4.3, at least if I'm understanding correctly. Getting Whonix 18 into R4.3 now would be very useful because then if it triggers a deluge of test failures for whatever reason, we'll know before R4.3's release, not after.

@adrelanos Thoughts on the above?

[marmarek]

If you decide to go this way anyway, let me know when "bookworm" branch is created.

[marmarek]

And yes, I agree adding Whonix 18 sooner than later is a good idea.

[adrelanos]

Branches have been created:

qubes-template-kicksecure:

• bookworm
• trixie

qubes-template-whonix:

• bookworm
• trixie

Best to use distinctly named branch names only going forward probably.

Quote @ArrayBolt3

At least in this specific instance though I think that's fine since Whonix 18 will not be made available for Qubes R4.2 (to my awareness), and Whonix 17 won't be supported on Qubes R4.3, at least if I'm understanding correctly. Getting Whonix 18 into R4.3 now would be very useful because then if it triggers a deluge of test failures for whatever reason, we'll know before R4.3's release, not after.

Exactly.