Bug#913913: Bug#931524: security.debian.org: bullseye security updates may be silently skipped on systems using apt pinning
Julian Andres Klode : > 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. [...] > Anyhow, we've got two years to fix this, no need to rush a "fix" out > now. One year has passed without rushing a fix, or any other action. Are there any plans to address the issue before security updates start breaking?
Bug#913913: Bug#931524: security.debian.org: bullseye security updates may be silently skipped on systems using apt pinning
On Mon, Jul 08, 2019 at 08:26:50AM +0200, Piotr Engelking wrote: > Julian Andres Klode : > > > > 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
Bug#913913: Bug#931524: security.debian.org: bullseye security updates may be silently skipped on systems using apt pinning
Julian Andres Klode : > > 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)
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 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
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 : > > > 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
Bug#913913: Bug#931524: security.debian.org: bullseye security updates may be silently skipped on systems using apt pinning
Salvatore Bonaccorso : > 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.
Bug#913913: Bug#931524: security.debian.org: bullseye security updates may be silently skipped on systems using apt pinning
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
Bug#931524: security.debian.org: bullseye security updates may be silently skipped on systems using apt pinning
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
