Heads up: apt depreciates SHA1 signatures in 2026. Unfortunately, the repositories still uses SHA1 in their signing key, so an update is necessary. This concerns all PureOS releases, AFAIK.
I already get this warning:
Warning: https://repo.pureos.net/pureos/dists/<DISTRO_VERSION>/InRelease: Policy will reject signature within a year, see --audit for details
Audit gives me the following deadline: 2026-02-01T00:00:00Z, after that, SHA1-keys will be rejected.
Is that maybe x86 only? I don’t recall seeing any complaints on the Librem 5.
(I guess onwards and upwards though, and it will eventually be the same on the Librem 5.)
The internet says that you can override this rejection temporarily if you have to but obviously it would be less hassle for customers if Purism upgraded the signature algorithm before 1 Feb.
Nope. Just me being on a more recent apt version (namely the one to be found in dawn (yes, yes, yes, beta, I know 
)). Even if older apt versions don’t complain, it is still a security issue. Version 2.9.19 of apt has these changes regarding secure signing algorithms. See here: apt/debian/changelog at main · Debian/apt · GitHub
OK. Well, as I implied, it will eventually be the same for everyone else on the Librem 5.
Thanks, I have this on our tracker: apt in Dawn will reject PureOS release files starting in 2026-02 (#73) · Issues · PureOS / Tasking · GitLab
amber, byzantium and crimson hasn’t been ported. It would be nice if they would also be ported to the new singning algorithm.
Thank you! 
Amber and Byzantium won’t as this would break old images.
Maybe Crimson could, I’ll consider that.
Dawn has used the new keys for many months already. Landing was switched recently.
Not even byzantium-security? I need it for old java versions.
If we could switch byzantium-security without breaking things, we could switch all of byzantium-* too.
Byzantium is at the end of its life anyway.
I don’t know exactly what @dos is referring to but there is a generic risk in upgrading repo security i.e. that you create a Catch 22 for the user.
This arises where the user running old software can’t upgrade to the new software that would recognise the new repo security because the old software won’t recognise the new repo security. At best, that forces the user running old software to use non-default options so as to override the problem (and to ignore the potential security risk).
Given that @dos will presumably some day in the not too distant future be wanting byzantium users to do an in-place upgrade to crimson, we want the best possible chance that that is a smooth upgrade for everyone - despite the great variety of what packages and what package versions customers may have installed.
One challenge is that you can get users doing that exact upgrade years after the upgrade is first available because they are not glued to this forum and because (in some environments) they wrongly expect the major release upgrade to happen automatically, just as everyday updates do. And that kind of user may also be running a really old set of byzantium packages. (It is generally advised when doing an in-place major release upgrade to ensure first that the current major release is fully up to date.)
It’s still the default thingy to download, which would make it the current stable, so that argument doesn’t really count.
Debian could do that. They even have updated it for at least some of the EOL versions. Tested buster. So, it seems to be possible, even if it may be challenging,
Anyways, thank you for your efforts.
If the key has already existed in the keyring, it can switched. Debian is pretty good at planning these things ahead.
In PureOS, only crimson images are guaranteed to contain the new key as it was only added in 2024, and a bug in pureos-archive-keyring package caused the new key to not be installed into apt keyring on upgrades until ~2 weeks ago, so byzantium installations from before the key was added couldn’t use it even if fully upgraded until very recently - so switching byzantium is basically out of the question at this point, once it becomes relatively safe to switch (assuming we’re fine with breaking old images) it will be long abandoned.
Plot twist:
I have took another look and it turns out that Laniakea already lets us use multiple signing keys (somewhat missed that earlier), so this solves all the troubles. It’s also a good news because it turns out I was wrong in the post above - earliest Librem 11 crimson images also lacked the new key, so we wouldn’t be able to switch it for crimson either. We can use both though, and now all older suites (amber, byzantium and crimson) are doing just that. dawn, landing and octarine use only the new key as the old one isn’t needed there.
It is. But it requires planning and you have to be confident that all customers have actually applied the necessary updates in the existing major release before they try a major release upgrade etc. etc..
Speaking generically, Linux distros that eschew telemetry and eschew coercion are at a disadvantage.
Consider how it might work with Microsoft Windows. In 25+ pages of legalese that you didn’t read and just clicked through, you agreed that Microsoft can basically do anything that is legal in your country.
They therefore already know what updates you have applied and anything else that they ‘need’ to know (and hence they know what percentage of their customer base will be broken by certain courses of action on their part).
And if they want a specific course of action not to break anyone, they just force the needed update on you. (Unless of course you pull your Windows computer off the internet altogether but then you won’t either be updating or be broken by an update.)
Does a typical Linux user like telemetry? like coercion? I think not.
For all Purism knows, there might be customers still running amber (and they may eventually decide that they want to run crimson but I suspect they might have to reflash in order to achieve that directly).
@dos I appreciate the effort you have put into this. It all works fine now. Thank you! HUGOPS to you.