Bug#1041708: apt: Manpages have wrong advice on APT::Default-Release preventing security updates
On Sat, Aug 19, 2023 at 06:14:54PM +0200, Daniel Gröber wrote:
> Hi,
>
> On Sat, Aug 19, 2023 at 04:53:09PM +0200, Raphael Hertzog wrote:
> > > The problem is that regex is NOT supported at the moment.
> >
> > Urgh, and you did not complain that the release notes actually encourage
> > users to do that?
>
> Yeah, that seems less than ideal. Brings me back to thinking we should
> change the security codename to something that's not going to need these
> hacky regexes then.
>
> Since $release/security is not well liked for unclear ("dak") reasons
> (please someone elaborate if possible), perhaps an approach based on
> Ubuntu's is less controvertial.
>
> In debian-security/bookworm-security we have this right now
>
> Origin: Debian
> Label: Debian-Security
> Suite: stable-security
> Version: 12
> Codename: bookworm-security
>
> and we need the regex becuase $codename/$suite doesn't match "bookworm",
> "bookworm/*" or stable, stable/* resp. Compare this to what Ubuntu uses:
>
> Origin: Ubuntu
> Label: Ubuntu
> Suite: kinetic-security
> Version: 22.10
> Codename: kinetic
>
> Here APT::Default-Release "kinetic" would match just fine. Just seems they
> don't support the "stable" alias like we do. Could we use this to cover
> both use-cases:
>
> Origin: Debian
> Label: Debian-Security
> Suite: stable
> Codename: bookworm
>
> Now no weird hacks are neceessary APT::DefaultRelease "bookworm" or
> "stable" will match the security repos just fine.
>
> Users that _really_ want to do weird things to the security repo can still
> use a "label" match in apt/preferences like `Pin: release
> l=Debian-Security`. I think you'd be able to combine this with a codename
> match to be specific about which release too: `Pin: release
> l=Debian-Security n=bookworm` but don't quote me on that until someone
> tests it.
>
> I don't see any real downsides to this approach other than "ugh more
> change".
I think ultimately APT::Default-Release has been deprecated[1] in
a configuration files many many cycles ago, and the current
behavior is much more meaningful on the command-line, both
in cases of apt install foo -t bookworm and apt install foo/bookworm
to specifically say you want stuff in bookworm and not in updates
or security (that is, you may want to downgrade to the latest
point release or install from it and ignore a buggy security
update).
I have a very strong dislike for the Ubuntu behavior because
it completely breaks user expectations.
In conclusion, I think that while this is a regression for
a very small minority of people, the current status quo is
ultimately an improvement in behavior.
I am amenable to add a warning to apt in case APT::Default-Release
is set in apt.conf such that users get a hint their configuration
is wrong
[1] by way of being not set up anymore, nor recommended in release
notes.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Bug#1041708: apt: Manpages have wrong advice on APT::Default-Release preventing security updates
Hi,
On Sat, Aug 19, 2023 at 04:53:09PM +0200, Raphael Hertzog wrote:
> > The problem is that regex is NOT supported at the moment.
>
> Urgh, and you did not complain that the release notes actually encourage
> users to do that?
Yeah, that seems less than ideal. Brings me back to thinking we should
change the security codename to something that's not going to need these
hacky regexes then.
Since $release/security is not well liked for unclear ("dak") reasons
(please someone elaborate if possible), perhaps an approach based on
Ubuntu's is less controvertial.
In debian-security/bookworm-security we have this right now
Origin: Debian
Label: Debian-Security
Suite: stable-security
Version: 12
Codename: bookworm-security
and we need the regex becuase $codename/$suite doesn't match "bookworm",
"bookworm/*" or stable, stable/* resp. Compare this to what Ubuntu uses:
Origin: Ubuntu
Label: Ubuntu
Suite: kinetic-security
Version: 22.10
Codename: kinetic
Here APT::Default-Release "kinetic" would match just fine. Just seems they
don't support the "stable" alias like we do. Could we use this to cover
both use-cases:
Origin: Debian
Label: Debian-Security
Suite: stable
Codename: bookworm
Now no weird hacks are neceessary APT::DefaultRelease "bookworm" or
"stable" will match the security repos just fine.
Users that _really_ want to do weird things to the security repo can still
use a "label" match in apt/preferences like `Pin: release
l=Debian-Security`. I think you'd be able to combine this with a codename
match to be specific about which release too: `Pin: release
l=Debian-Security n=bookworm` but don't quote me on that until someone
tests it.
I don't see any real downsides to this approach other than "ugh more
change".
--Daniel
Bug#1041708: apt: Manpages have wrong advice on APT::Default-Release preventing security updates
Hi, Le samedi 19 août 2023, David Kalnischkies a écrit : > > Agreed. It would be nice to document that we can use regex here and > > that it actually makes sense to do so as most Debian release are actually > > composed of multiple repositories. > > The problem is that regex is NOT supported at the moment. Urgh, and you did not complain that the release notes actually encourage users to do that? > It happens to work in most commands, but it e.g. doesn't in 'source'. > > Before we could (leaving alone the question if we should) document it > as supported, we would need to check all commands and fix those which do > not work with it. Nobody did in the last couple of years. > > So the only reasonable solution for this request so far is to document > it explicitly as not supported… which helps exactly nobody. Well, it's always nice to document the known limitations and thus invite users to prefer explicit pinning over usage of APT::Default-Release which is commonly used in a configuration file. > Step back and question why you want to use the option. There are > probably easier and simpler ways. Adding backports e.g. doesn't need > pinning at all (it comes by default with 100). Adding unstable to stable > might be a bad idea to begin with, but is certainly better dealt with > a pin against unstable rather than trying to catch all your "good" > "stable" repos in a regex to filter out the one bad "unstable" apple. I understand that but in my mental model, it was more like "as soon as you add other suites, make sure to document the preferred release with APT::Default-Release" instead of the opposite (i.e. make sure to pin down the repositories that you don't want to use by default). Clearly I have often used that when I added a newer release in sources.list (be it unstable/testing or just stable on an oldstable server or similar). Is there any difference of behaviour between reducing pin of alternate releases to a value < 500 vs increasing the priority of the desired release to 990? > In preferences the regex actually works and is documented, which is the > deeper reason behind APT::Default-Release working with regex or not as > certain commands can rely on the preferences infrastructure while > a command like 'source' can currently not and hence implements it > differently without support for a lot of things possible elsewhere. Maybe it can be documented as a limitation of the source command instead of refusing to acknowledging what works and what's used? > If you can come up with a list of use cases for that option (personally, > I don't see a good one) without too much by-catch we might be able to > implement a transition notice like I did for non-free-firmware. > Too late, too little, but at least it would prevent future misuse. Maybe you should deprecate the option in the configuration file and invite users to switch to preferences? I don't know what's best. It would still be nice to have a simple syntax that would match the -security repo, the -updates repo and the main repo for a given release... but maybe it should rely on a new "PartOfRelease" field in the various "Release" files or something like that. Cheers, -- Raphaël Hertzog signature.asc Description: PGP signature
Bug#1041708: apt: Manpages have wrong advice on APT::Default-Release preventing security updates
On Fri, Aug 18, 2023 at 11:24:22AM +0200, Raphael Hertzog wrote: > > > As you may have noticed, the 'stable' doesn't include 'stable-updates' > > > either and that isn't new – and also part of the reason for this funny > > > regex. I was surprised then I discovered that entry the first time in > > > the release notes as we were never asked about it. > > > > Looking at the apt.conf and apt_preference manpages there is still no > > mention of the regex support, perhaps this should be documented there? > > Agreed. It would be nice to document that we can use regex here and > that it actually makes sense to do so as most Debian release are actually > composed of multiple repositories. The problem is that regex is NOT supported at the moment. It happens to work in most commands, but it e.g. doesn't in 'source'. Before we could (leaving alone the question if we should) document it as supported, we would need to check all commands and fix those which do not work with it. Nobody did in the last couple of years. So the only reasonable solution for this request so far is to document it explicitly as not supported… which helps exactly nobody. To quote myself from this very thread: | Anyway, easiest way to not have these problems is to not use the option | at all. Step back and question why you want to use the option. There are probably easier and simpler ways. Adding backports e.g. doesn't need pinning at all (it comes by default with 100). Adding unstable to stable might be a bad idea to begin with, but is certainly better dealt with a pin against unstable rather than trying to catch all your "good" "stable" repos in a regex to filter out the one bad "unstable" apple. In preferences the regex actually works and is documented, which is the deeper reason behind APT::Default-Release working with regex or not as certain commands can rely on the preferences infrastructure while a command like 'source' can currently not and hence implements it differently without support for a lot of things possible elsewhere. If you can come up with a list of use cases for that option (personally, I don't see a good one) without too much by-catch we might be able to implement a transition notice like I did for non-free-firmware. Too late, too little, but at least it would prevent future misuse. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1041708: apt: Manpages have wrong advice on APT::Default-Release preventing security updates
Hello, Le samedi 22 juillet 2023, Daniel Gröber a écrit : > > (eventually an update/security fix will be part of stable via a point > > release, so such a setting considerably delays the updates, but doesn't > > prevent them as such. While I wouldn't recommended it, there might be > > people who desire exactly this behaviour…) > > Ah, I didn't realise this is something that can be relied on. In that case > the problem is a lot less concerning indeed. This holds true only for the first 3 years where there are point releases that are generated. Afterwards, the security updates stay in the security repository and are never merged. So we can't really rely on this only. > > As you may have noticed, the 'stable' doesn't include 'stable-updates' > > either and that isn't new – and also part of the reason for this funny > > regex. I was surprised then I discovered that entry the first time in > > the release notes as we were never asked about it. > > Looking at the apt.conf and apt_preference manpages there is still no > mention of the regex support, perhaps this should be documented there? Agreed. It would be nice to document that we can use regex here and that it actually makes sense to do so as most Debian release are actually composed of multiple repositories. Cheers, -- Raphaël Hertzog
Bug#1041708: apt: Manpages have wrong advice on APT::Default-Release preventing security updates
Package: apt Version: 2.6.1 Severity: important Tags: security X-Debbugs-Cc: d...@darkboxed.org, Debian Security Team Dear Maintainer, apt's manpages contain references to APT::Default-Release which give wrong advice on how to set it in light of the changes to the debian-security repo Codename as of bullseye[1]: Setting APT::Default-Release to a plain codename such as "stable" or "bookworm" will have the disastrous consequence of preventing security updates from bein considered when upgrading. [1]: https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive Please update any Default-Release references with the advice from the bullseye release-notes at [1]. Thanks, --Daniel PS: I think this change of debian-security Codename was a collossal mistake and I'm looking into getting this fixed properly by changing the codename to $codename/security but the updated advice should be safe in the face of that change.
