Bug#913913: Bug#931524: security.debian.org: bullseye security updates may be silently skipped on systems using apt pinning
On Sun, Jul 07, 2019 at 04:59:03PM +0200, Piotr Engelking wrote:
> Salvatore Bonaccorso <carnil@debian.org>:
>
> > I do not think this will be reverted, but time will show. There was
> > already an earlier intention to do this to get consistency across the
> > archive:
> >
> > https://lists.debian.org/debian-security/2015/12/msg00015.htm
> >
> > But back then this was not possible to switch. Then the buster release
> > was the optimal point in time to retry:
> >
> > https://lists.debian.org/debian-security/2019/06/msg00015.html
> >
> > This quarantees that actually now the archive is in itself more
> > consistent and security archive is not anymore a special case for
> > future releases.
> >
> > User will anyway need to update the sources.list when switching to
> > bullseye, so the need of touching sources.list makes it as well
> > equally easy to then adjust the respective distribution component of
> > the URL.
>
> Change of the URL component to bullseye-security is not a problem.
>
> The problem is that the bullseye-security Release file sets the
> Suite field to testing-security. This interacts badly with commonly
> recommended (by, among others, the apt_preferences(5) manual page)
> APT pinning configuration of systems running Debian testing:
>
> Package: *
> Pin: release o=Debian, a=testing
> Pin-Priority: 800
>
> 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.
>
> > testing-security is only populated very late in the freeze of a
> > release, in deep freeze when unblock requests are not anymore possible
> > and still packages should be released for security to have them from
> > day 0 in the new release.
>
> This, on one hand, makes fixing the problem not urgent. On another,
> it makes users even less likely to discover the problem on their own.
>
> The solutions I can think of are:
>
> * Do not do anything. This is leaves systems in a potentially
> vulnerable state.
This seems the "best" outcome. In any case, we have about 2 years to
figure this out and should keep things this way for now.
>
> * 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.
Ubuntu would use:
Codename: bullseye
Suite: bullseye-security
but that would not help you either for a= pins, only for n pins (or ones
without an a= or n=). I also find it super annoying as bullseye pins now
apply to bullseye-security, and I can't pin bullseye release. It also breaks
testing-security as a name.
That said, we might want a way to specify more aliases. Having two names
for a distribution is severily limiting, especially if we want to allow
people to specify versions instead.
Maybe we should have more Release file fields (Codename-Alias, Suite-Alias,
Alias)?
>
> * 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.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Reply to: