Migrate to Bullseye

[eloquence]

Debian Buster will reach end-of-life in August 2022. While that's not right around the corner, migrating to Bullseye will also bring the benefit of more up-to-date system packages (e.g., Python/pip), and migrations are easier with fewer production users, so we may want to prioritize this migration well before the EOL hits.

[conorsch]

D11 templates are now available for Qubes 4.0 (and 4.1). We'll need to update our builder logic to try it out: https://github.com/freedomofpress/qubes-template-securedrop-workstation

[conorsch]

Took a quick spike at this. While not strictly coupled, it makes sense to ship these changes as part of the migration to Qubes 4.1 (#600). A few notes:

• securedrop-workstation-grsec implicitly depends on dkms for u2mfn module handling; none of that is necessary under 4.1, so build a new metapackage for bullseye/4.1 that simplifies the postinst: https://github.com/freedomofpress/securedrop-debian-packaging/blob/c0167ee9f73feab10bf73d1dd1706309eddf4591/securedrop-workstation-grsec/debian/postinst#L45-L51
• paxctld has been dropped from the debian stable archives; we'll need to host it ourselves in the FPF apt repos
• while not a hard requirement, we might as well take this opportunity to move the workstation to the 5.15.x kernel series, same as we recently did for the server builds
• as expected, the qubes-template-securedrop-workstation logic will need a few tweaks to emit a working build. that's par for the course, and we'll handle as they crop up.

[legoktm]

• paxctld has been dropped from the debian stable archives; we'll need to host it ourselves in the FPF apt repos

It was removed under the assumption that it wasn't useful anymore (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969218), which isn't exactly true. We can ask the original maintainer if they're interested in re-uploading it or I can reintroduce it (happy to pair with someone to share knowledge!!) and get it into bullseye-backports.

[conorsch]

@legoktm Honestly, I kind of agree with the decision that Debian made there: paxctld only works with grsec, grsec isn't available in the Debian repos, so paxctld doesn't belong there, either. Customers of grsec can obtain patches from https://grsecurity.net/download (clicking through will require basic auth creds), but the paxctld packages are freely/publicly available, with detached sigs. Given how infrequently paxctld is updated, fetching, verifying, and PRing into the LFS repos should be a "good enough" solution for us, and we won't have to muck around with backports or apt-preferences to support it.

Unrelated to this issue, but presumably the next Ubuntu LTS will also lack it, meaning we'll want it in place on the SD servers, as well, so hosting in our apt repo makes sense to me. Unfortunately, rehosting it ourselves via download doesn't leverage any of the great work you've done to mirror tor packages (freedomofpress/securedrop-apt-test#128), but still strikes me as the lowest maintenance option over time. Please let me know if you disagree!

[legoktm]

In general my perspective is that things are easier when we have an upstream-first attitude. In the case of Debian, in the long run it's easier to have Debian packages maintained in Debian itself. We get access to Debian-infra tools like lintian, piuparts, and then people who do rebuilds to make sure packages are compatible with new gcc, binutils, etc. so if something is wrong, we know way ahead of time rather than when we try to upgrade to a new OS.

In the short-term, yeah, we'll probably need to host our own version of the package (I do think it would be nice for us to do our own builds instead of using the grsec-built packages, which were built on Debian stretch for some reason). And I would think/hope/expect that the work we do is of good enough quality to also be re-used in Debian, so it's not additional extra work. The obvious caveat is that things I consider trivial or straightforward w/r to Debian and packaging are obviously not for everyone else, but the solution for that is more practice and knowledge sharing :-)

Also the more we do upstream, we'll notice things that affect us sooner at a time when we can still fix them before it's too late. E.g. I noticed that dh-virtualenv was going to miss the next Ubuntu LTS because it wasn't in Debian testing, so I looked into it and downgraded the bug's severity, and it re-entered testing.

[conorsch]

Took a spike at building a Bullseye template for Qubes 4.1, using 5.15.x grsec kernels. Worked rather well:

Notably I did not repackage the SDW components, such as securedrop-client, for Bullseye, so I haven't verified the application performance yet. Still, this spike serves to validate the WIP changes to the template build logic in https://github.com/freedomofpress/qubes-template-securedrop-workstation. I'll clean up those branches and open some draft PRs for future reference. In particular, looking forward to discussing those changes in detail with @creviera.

[eaon]

This happened :)