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

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Piotr Engelking
Package: security.debian.org
Severity: normal
Tags: security

With the release of buster, testing security updates switched from
Suite: testing to Suite: testing-security. This silently breaks
security updates on systems using apt pinning to elevate the priority
of testing packages.

Also, bug #913913 makes this already non-obvious configuration problem
even harder for users to discover and to correctly fix.

Please consider reverting this change.


-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'unstable'), (600, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8),
LANGUAGE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Reply | Threaded
Open this post in threaded view
|

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

Francesco Poli (wintermute)
On Sun, 7 Jul 2019 09:30:13 +0200 Piotr Engelking <[hidden email]> wrote:

> Package: security.debian.org
> Severity: normal
> Tags: security
>
> With the release of buster, testing security updates switched from
> Suite: testing to Suite: testing-security. This silently breaks
> security updates on systems using apt pinning to elevate the priority
> of testing packages.
>
> Also, bug #913913 makes this already non-obvious configuration problem
> even harder for users to discover and to correctly fix.
>
> Please consider reverting this change.
Hello,
I am another user hit by this issue:


  # cat /etc/apt/sources.list
  deb http://deb.debian.org/debian testing main
  deb http://deb.debian.org/debian unstable main
 
  deb http://deb.debian.org/debian-security testing-security main
  # cat /etc/apt/preferences
  Package: *
  Pin: release o=Debian,a=testing
  Pin-Priority: 800
  # apt update
  Hit:1 http://deb.debian.org/debian testing InRelease
  Hit:2 http://deb.debian.org/debian unstable InRelease
  Hit:3 http://deb.debian.org/debian-security testing-security InRelease
  Reading package lists... Done
  Building dependency tree      
  Reading state information... Done
  All packages are up to date.
  # apt policy
  Package files:
   100 /var/lib/dpkg/status
       release a=now
   500 http://deb.debian.org/debian unstable/main amd64 Packages
       release o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64
       origin deb.debian.org
   800 http://deb.debian.org/debian testing/main amd64 Packages
       release o=Debian,a=testing,n=bullseye,l=Debian,c=main,b=amd64
       origin deb.debian.org
  Pinned packages:


Now, I would like to debug my Pin-Priority setup (see also bug
[#931524]), but "apt policy" says nothing about the Pin-Priority assigned to
"deb http://deb.debian.org/debian-security testing-security main"!

How can I check what Pin-Priority apt assigns to a repository which
does not yet include any packages?
How can I look at what values it sees for the "o", "a", "n", "l", "c",
and "b" fields of such a repository?

I need to do so, *before* some packages become available with the
*wrong* Pin-Priority!


Please let "apt policy" also show empty sources along with their
Pin-Priority and field values.
Or, otherwise, please implement a command-line option to get this
additional output.

Thanks for your time and dedication!
Bye.



[#931524]: <https://bugs.debian.org/931524>

--
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Salvatore Bonaccorso-4
In reply to this post by Piotr Engelking
Hi

[reassigned the package to ftp.debian.org as while it affects security
team, this is on the archive side]

On Sun, Jul 07, 2019 at 09:30:13AM +0200, Piotr Engelking wrote:

> Package: security.debian.org
> Severity: normal
> Tags: security
>
> With the release of buster, testing security updates switched from
> Suite: testing to Suite: testing-security. This silently breaks
> security updates on systems using apt pinning to elevate the priority
> of testing packages.
>
> Also, bug #913913 makes this already non-obvious configuration problem
> even harder for users to discover and to correctly fix.
>
> Please consider reverting this change.

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.

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.

Does this clarify your question or concern?

Regards,
Salvatore

Reply | Threaded
Open this post in threaded view
|

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

Piotr Engelking
Salvatore Bonaccorso <[hidden email]>:

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

Reply | Threaded
Open this post in threaded view
|

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

Julian Andres Klode-4
On Sun, Jul 07, 2019 at 04:59:03PM +0200, Piotr Engelking wrote:

> Salvatore Bonaccorso <[hidden email]>:
>
> > 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 | Threaded
Open this post in threaded view
|

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

Julian Andres Klode-4
On Sun, Jul 07, 2019 at 05:23:01PM +0200, Julian Andres Klode wrote:

> 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)?

Maybe we should have a Pocket field, and then you'd have

Codename: bullseye
Suite: testing
Pocket: security

and you could pin a=testing, p=security.

--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

Reply | Threaded
Open this post in threaded view
|

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

Piotr Engelking
In reply to this post by Julian Andres Klode-4
Julian Andres Klode <[hidden email]>:

> > 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 | Threaded
Open this post in threaded view
|

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

Julian Andres Klode-4
On Mon, Jul 08, 2019 at 08:26:50AM +0200, Piotr Engelking wrote:

> Julian Andres Klode <[hidden email]>:
>
> > > 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.

ugh.

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

e.g. for Ubuntu, using the devel symlink for eoan, you get:

W: Conflicting distribution: http://de1.archive.ubuntu.com/ubuntu devel InRelease (expected devel but got eoan)

Same thing would apply in this case and it would say:

W: Conflicting distribution: http://security.debian.org/debian-security testing-security InRelease (expected testing-security but got testing)

or it might even say "got bullseye", not entirely sure.

Anyhow, we've got two years to fix this, no need to rush a "fix" out
now.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en