Bug#913913: Bug#931524: security.debian.org: bullseye security updates may be silently skipped on systems using apt pinning

[Piotr Engelking <inkerman42@gmail.com>]

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.

> 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.

* 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.

* 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.