Comment 2 for bug 2060721

The same caveat applies to -updates, but there is a question of whether we should ship 2.8.0 as this or make 2.8.0 different, I did not push a tag for it yet.

i.e. given that this is a stable release update that will break PPAs users currently have warnings for, it might make sense to make it break that a couple months down the road after we have a transition period, i.e. we can "timebomb" things by making apt treat the weak keys as expiring in August (August because we really want this sorted out by the point release when the big wave of 22.04 users upgrades).

We could also introduce a new version of software-properties-common that adds PPA key refresh. We should then trigger that by apt postinst, or in the software-properties-common postinst. I do not believe we need to enforce a strict ordering relationship here, so 2.8.0 as is should technically be good to go.

It's understandable that breaking existing repositories in a stable release is not optimal, however the warnings don't work as a security mechanism - we do not show you which weak keys are trusted, just which weak keys were used to sign the repository:

Hence if you have a 1024R key and a 4096R that can sign a repository, but it's signed by the 4096R key now, you don't see the 1024R key, and an attacker could resign the repository with it and silently attack you.

So this is something we do need to target for the first point release; we want users upgrading from 22.04 to not end up in the transitional stage where they have warnings.