info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Setting APT::Default-Release prevents installation of security updates in bookworm!?
9 views
Skip to first unread message
Daniel Gröber
Jul 20, 2023, 5:10:04 PM7/20/23
to
Hi debian-security,
I've just noticed something rather distressing. As part of my usual Debian
installation I set `APT::Default-Release "stable";` which causes a change
of apt priorities for packages from this release (or so I thought) from the
usual 500 to 990. This is recommended in various places, but I don't recall
if d-i sets this up by default or not.
It seems packages from the debian-security repository are not affected by
this increased priority and will not get intalled as a result. Note:
`apt-cache policy` tends to lie. I observed this by actually trying to
install a kernel update from d-security that should get installed but
doesn't.
As soon as I remove the Default-Release line from apt.conf the update gets
offered for installation. Has anyone else observed this or is something
broken in my apt config somewhere?
--Daniel
I've just noticed something rather distressing. As part of my usual Debian
installation I set `APT::Default-Release "stable";` which causes a change
of apt priorities for packages from this release (or so I thought) from the
usual 500 to 990. This is recommended in various places, but I don't recall
if d-i sets this up by default or not.
It seems packages from the debian-security repository are not affected by
this increased priority and will not get intalled as a result. Note:
`apt-cache policy` tends to lie. I observed this by actually trying to
install a kernel update from d-security that should get installed but
doesn't.
As soon as I remove the Default-Release line from apt.conf the update gets
offered for installation. Has anyone else observed this or is something
broken in my apt config somewhere?
--Daniel
Paul Wise
Jul 20, 2023, 10:20:04 PM7/20/23
to
On Thu, 2023-07-20 at 22:12 +0200, Daniel Gröber wrote:
> It seems packages from the debian-security repository are not affected by
> this increased priority and will not get intalled as a result.
This was documented in the release notes for Debian bullseye:
> It seems packages from the debian-security repository are not affected by
> this increased priority and will not get intalled as a result.
https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive
I have updated a few wiki pages that mention APT::Default-Release too.
https://wiki.debian.org/DebianUnstable?action=diff&rev1=144&rev2=145
https://wiki.debian.org/DebianEdu/Status/Bullseye?action=diff&rev1=107&rev2=108
https://wiki.debian.org/Wajig?action=diff&rev1=20&rev2=21
https://wiki.debian.org/FunambolInstallation?action=diff&rev1=9&rev2=10
If there is other documentation of APT::Default-Release that should get
updated, please let us know so that we can fix it.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Daniel Gröber
Jul 21, 2023, 5:10:04 AM7/21/23
to
Hi Paul,
On Fri, Jul 21, 2023 at 10:17:28AM +0800, Paul Wise wrote:
> On Thu, 2023-07-20 at 22:12 +0200, Daniel Gröber wrote:
>
> > It seems packages from the debian-security repository are not affected by
> > this increased priority and will not get intalled as a result.
>
> This was documented in the release notes for Debian bullseye:
>
> https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive
Now that you mention it I remember reading this and getting quite
irritated. Probably why I forgot about it.
Do you have any references on how this decision came to be?
> I have updated a few wiki pages that mention APT::Default-Release too.
>
> https://wiki.debian.org/DebianUnstable?action=diff&rev1=144&rev2=145
> https://wiki.debian.org/DebianEdu/Status/Bullseye?action=diff&rev1=107&rev2=108
> https://wiki.debian.org/Wajig?action=diff&rev1=20&rev2=21
> https://wiki.debian.org/FunambolInstallation?action=diff&rev1=9&rev2=10
>
> If there is other documentation of APT::Default-Release that should get
> updated, please let us know so that we can fix it.
One mention I found is in Raphaël and Roland's DAH (now in CC):
https://debian-handbook.info/browse/stable/sect.apt-get.html#sect.apt-upgrade
The places I'm most concerned about, people's brains and random web sites,
aren't so easily fixed unfortunately. Advice to set this is splattered all
over the web, I really don't understand why we made a change so seemingly
ill advised as this?
A web search for "Debian Default-Release security" didn't reveal anything
talking about this problem, especially not our release notes, so I think
this change didn't get the publicity it deserves at the very least.
What I don't understand is why the security repo codename wasn't changed to
$codename/security? Wouldn't that be handled correctly by APT? Unless the
/update string in particular had special handling?
Thanks,
--Daniel
On Fri, Jul 21, 2023 at 10:17:28AM +0800, Paul Wise wrote:
> On Thu, 2023-07-20 at 22:12 +0200, Daniel Gröber wrote:
>
> > It seems packages from the debian-security repository are not affected by
> > this increased priority and will not get intalled as a result.
>
> This was documented in the release notes for Debian bullseye:
>
> https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive
irritated. Probably why I forgot about it.
Do you have any references on how this decision came to be?
> I have updated a few wiki pages that mention APT::Default-Release too.
>
> https://wiki.debian.org/DebianUnstable?action=diff&rev1=144&rev2=145
> https://wiki.debian.org/DebianEdu/Status/Bullseye?action=diff&rev1=107&rev2=108
> https://wiki.debian.org/Wajig?action=diff&rev1=20&rev2=21
> https://wiki.debian.org/FunambolInstallation?action=diff&rev1=9&rev2=10
>
> If there is other documentation of APT::Default-Release that should get
> updated, please let us know so that we can fix it.
https://debian-handbook.info/browse/stable/sect.apt-get.html#sect.apt-upgrade
The places I'm most concerned about, people's brains and random web sites,
aren't so easily fixed unfortunately. Advice to set this is splattered all
over the web, I really don't understand why we made a change so seemingly
ill advised as this?
A web search for "Debian Default-Release security" didn't reveal anything
talking about this problem, especially not our release notes, so I think
this change didn't get the publicity it deserves at the very least.
What I don't understand is why the security repo codename wasn't changed to
$codename/security? Wouldn't that be handled correctly by APT? Unless the
/update string in particular had special handling?
Thanks,
--Daniel
Paul Wise
Jul 22, 2023, 4:01:35 AM7/22/23
to
On Fri, 2023-07-21 at 11:04 +0200, Daniel Gröber wrote:
> Do you have any references on how this decision came to be?
I think it was about making the suite naming more intuitive, consistent
> Do you have any references on how this decision came to be?
with other suites and possibly also some dak implementation concerns.
> One mention I found is in Raphaël and Roland's DAH (now in CC):
> https://debian-handbook.info/browse/stable/sect.apt-get.html#sect.apt-upgrade
> The places I'm most concerned about, people's brains and random web sites,
> aren't so easily fixed unfortunately. Advice to set this is splattered all
> over the web, I really don't understand why we made a change so seemingly
> ill advised as this?
>
> A web search for "Debian Default-Release security" didn't reveal anything
> talking about this problem, especially not our release notes, so I think
> this change didn't get the publicity it deserves at the very least.
>
> What I don't understand is why the security repo codename wasn't changed to
> $codename/security? Wouldn't that be handled correctly by APT? Unless the
> /update string in particular had special handling?
but at the end of the day reverting it is unlikely to happen, so
probably it is something everyone will just have to learn to live with.
Daniel Gröber
Jul 22, 2023, 10:00:06 AM7/22/23
to
Hi Paul,
On Sat, Jul 22, 2023 at 03:56:02PM +0800, Paul Wise wrote:
> > One mention I found is in Raphaël and Roland's DAH (now in CC):
> > https://debian-handbook.info/browse/stable/sect.apt-get.html#sect.apt-upgrade
>
> Probably better to file a bug about this, so it is tracked.
Ah, I didn't realise debian-handbook has a package in the archive :)
Done, Bug#1041706: debian-handbook: Wrong advice on APT::Default-Release preventing security updates.
> > What I don't understand is why the security repo codename wasn't changed to
> > $codename/security? Wouldn't that be handled correctly by APT? Unless the
> > /update string in particular had special handling?
>
> You will have to ask the apt developers and archive admins about this,
> but at the end of the day reverting it is unlikely to happen, so
> probably it is something everyone will just have to learn to live with.
I've had a quick look at the apt code now and indeed it seems to handle
$codename/$whatever as equivalent to $codename, see metaIndex::CheckDist.
I don't see why we couldn't revert this change. Anybody who's applied the
hack from the bullseye release-notes will be unaffected as the regex will
still match a plain code/suite-name but people who never applied this
advice will get their security updates back.
I've sent a bug to apt as well, just about the doc references for now:
Bug#1041708: apt: Manpages have wrong advice on APT::Default-Release
preventing security updates.
Who do I contact about the archive aspects? FTP-master or the
security-team? The security-team is in CC on the doc bugs so I'm hoping
they will see it anyway.
Thanks,
--Daniel
On Sat, Jul 22, 2023 at 03:56:02PM +0800, Paul Wise wrote:
> > One mention I found is in Raphaël and Roland's DAH (now in CC):
> > https://debian-handbook.info/browse/stable/sect.apt-get.html#sect.apt-upgrade
>
> Probably better to file a bug about this, so it is tracked.
Done, Bug#1041706: debian-handbook: Wrong advice on APT::Default-Release preventing security updates.
> > What I don't understand is why the security repo codename wasn't changed to
> > $codename/security? Wouldn't that be handled correctly by APT? Unless the
> > /update string in particular had special handling?
>
> You will have to ask the apt developers and archive admins about this,
> but at the end of the day reverting it is unlikely to happen, so
> probably it is something everyone will just have to learn to live with.
$codename/$whatever as equivalent to $codename, see metaIndex::CheckDist.
I don't see why we couldn't revert this change. Anybody who's applied the
hack from the bullseye release-notes will be unaffected as the regex will
still match a plain code/suite-name but people who never applied this
advice will get their security updates back.
I've sent a bug to apt as well, just about the doc references for now:
Bug#1041708: apt: Manpages have wrong advice on APT::Default-Release
preventing security updates.
Who do I contact about the archive aspects? FTP-master or the
security-team? The security-team is in CC on the doc bugs so I'm hoping
they will see it anyway.
Thanks,
--Daniel
Hannes von Haugwitz
Jul 22, 2023, 12:00:04 PM7/22/23
to
On Sat, Jul 22, 2023 at 03:56:02PM +0800, Paul Wise wrote:
> You will have to ask the apt developers and archive admins about this,
> but at the end of the day reverting it is unlikely to happen, so
> probably it is something everyone will just have to learn to live with.
What about to add a warning to apt if *-security or *-updates is
> but at the end of the day reverting it is unlikely to happen, so
> probably it is something everyone will just have to learn to live with.
configured in the sources list and `APT::Default-Release` is set but
does not match the security or updates repo?
Best regards
Hannes
Paul Wise
Jul 25, 2023, 12:10:04 AM7/25/23
to
On Sat, 2023-07-22 at 17:45 +0200, Hannes von Haugwitz wrote:
> What about to add a warning to apt if *-security or *-updates is
> configured in the sources list and `APT::Default-Release` is set but
> does not match the security or updates repo?
That seems like the right solution here, please file a bug on apt.
> What about to add a warning to apt if *-security or *-updates is
> configured in the sources list and `APT::Default-Release` is set but
> does not match the security or updates repo?
Please also check these packages and file bugs against any broken ones:
https://codesearch.debian.net/search?literal=1&q=APT%3A%3ADefault-Release
Some of these are probably best filed upstream instead of in Debian,
especially for issues in files not used by Debian like Dockerfiles.
Raphael Hertzog
Aug 18, 2023, 5:30:03 AM8/18/23
to
Hello,
On Fri, 21 Jul 2023, Daniel Gröber wrote:
> One mention I found is in Raphaël and Roland's DAH (now in CC):
> https://debian-handbook.info/browse/stable/sect.apt-get.html#sect.apt-upgrade
I also saw your associated bug report. Thanks for highlighting this
issue to me. I updated https://salsa.debian.org/hertzog/debian-handbook/-/issues/58
to make sure that we take care of documenting this as part of the next
book update.
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <her...@debian.org>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
On Fri, 21 Jul 2023, Daniel Gröber wrote:
> One mention I found is in Raphaël and Roland's DAH (now in CC):
> https://debian-handbook.info/browse/stable/sect.apt-get.html#sect.apt-upgrade
issue to me. I updated https://salsa.debian.org/hertzog/debian-handbook/-/issues/58
to make sure that we take care of documenting this as part of the next
book update.
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <her...@debian.org>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
0 new messages