Bug#913913: Bug#931524: security.debian.org: bullseye security updates may be silently skipped on systems using apt pinning
Julian Andres Klode <jak@debian.org>:
> > Now a=testing packages have higher priority than the a=testing-security
> > ones, which results in security updates not being installed. Another
> > method of pinning configuration, using APT::Default-Release, has
> > exactly the same effect.
>
> And this is a good thing IMO, as you want to be able to pin release
> over security.
Why? Anyway, this was already possible, using l=Debian and
l=Debian-Security.
> > * Change the suite from a=testing-security back to a=testing. This is
> > least work, but I don't know if it has any downsides I am unaware of.
>
> That means that testing-security does not work, as testing-security is
> not testing and apt will complain.
Which diagnostics are you talking about? I wasn't able to find it.
> > * Change the documentation to work with the current setting, and warn
> > the existing users. (In APT::Update::Post-Invoke, perhaps?) This may
> > be reasonable, and could be used to warn about other configuration
> > problems, like no security updates configured at all.
>
> This does not seem possible. I don't see how you'd figure out affected
> users.
No security updates configured:
* (o=Debian, a=testing) source
* no (o=Debian, a=testing-security) source
Security updates configured, but not applied:
* (o=Debian, a=testing) source has higher priority than
(o=Debian, a=testing-security) source
These two are trivial and take care of most configuration problems.
Package pins are more complicated. Once it prevents a particular
security update, we can detect it reliably, but it may be too late, as
some people do unattended upgrades:
* the candidate version of a package comes from (o=Debian, a=testing)
and is lower than a version from (o=Debian, a=testing-security)
Reply to: