Ian Fleming wrote: "Once is happenstance. Twice is coincidence. The
third time it's enemy action." I've only got as far as coincidence so
far, but it's still enough to make me wonder.

The following bugs on openssh both report problems with applying a
recent security update on bookworm, because it depends on a libssl3
version that was added to bookworm in a point release:

https://bugs.debian.org/1098272
https://bugs.debian.org/1099091

This is clearly (to my mind) a misconfiguration, so I've rejected them
as bugs on openssh: we don't support installing only security updates
and never upgrading to packages from new point releases, because those
aren't rigorously separate streams: security updates are built against
the stable suite and so may pick up versioned dependencies against it.
But seeing two users who seem to have their systems configured this way
makes me wonder what's going on. Does anyone know of documentation
somewhere that recommends configuring stable systems this way?

Thanks,

--
Colin Watson (he/him) [[email protected]]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 28/2/25 11:57, Colin Watson wrote:

Ian Fleming wrote: "Once is happenstance.  Twice is coincidence.  The
third time it's enemy action."  I've only got as far as coincidence so
far, but it's still enough to make me wonder.

No need to turn to paranoia in this case :)

[snip]

This is clearly (to my mind) a misconfiguration,

INDEED.  And maybe a (minor) documentation bug, given that Debian
installer would never enable *only* security updates....

My (humble) opinion reasoning on this is:   some admin, probably coming
from other environments/distros, understood that enabling ONLY security
updates would provide all the stability guarantees they want --- i.e. no incompatible upgrades during the lifecycle of the release.

so I've rejected them as bugs on openssh: we don't support installing
only security updates and never upgrading to packages from new point releases, because those aren't rigorously separate streams: security
updates are built against the stable suite and so may pick up
versioned dependencies against it.  But seeing two users who seem to
have their systems configured this way makes me wonder what's going
on.  Does anyone know of documentation somewhere that recommends
configuring stable systems this way?

Not in Debian, that I know of .... but I can easily understand where the reasoning that led to this misconfiguration came from; I have actually
seem them live :)

Humble suggestion to add an (overrideable) warning to APT to this
effect?  Something along the lines of "W: Configuring only security
updates for suite $suite is not officially supported, and can create installability conflicts"

    Stressing the "officially" here: it can work; will usually work.... until it doesn't (like for these bugs). But it's not the maintainer's fault.



Just my .02€. HTH

--
Parkinson's Law: Work expands to fill the time alloted to it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 2/28/25 19:57, Colin Watson wrote:

But seeing two users who seem to have their systems configured this way
makes me wonder what's going on.  Does anyone know of documentation somewhere that recommends configuring stable systems this way?

What is weird is that both have pin priority 500, so I wonder why the
newer version isn't selected.

The package in stable is also from a point release, so point releases
are available as well. My initial suspicion was "CD-ROM plus security
updates", which I'd find is a somewhat understandable combination that
is also broken.

I'd probably reassign to apt :>

Simon

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Feb 28, 2025 at 10:57:31AM +0000, Colin Watson wrote:

Ian Fleming wrote: "Once is happenstance. Twice is coincidence. The third time it's enemy action." I've only got as far as coincidence so far, but it's still enough to make me wonder.

The following bugs on openssh both report problems with applying a recent security update on bookworm, because it depends on a libssl3 version that
was added to bookworm in a point release:

https://bugs.debian.org/1098272
https://bugs.debian.org/1099091

This is clearly (to my mind) a misconfiguration, so I've rejected them as bugs on openssh: we don't support installing only security updates and never upgrading to packages from new point releases, because those aren't rigorously separate streams: security updates are built against the stable suite and so may pick up versioned dependencies against it. But seeing two users who seem to have their systems configured this way makes me wonder what's going on. Does anyone know of documentation somewhere that
recommends configuring stable systems this way?

As a datapoint, I have not seen documentation that recommends doing
this, but I have on occasion removed the main archive from my
sources.list leaving only security updates. I have done this post point
release when I do not yet have a window scheduled for a reboot post
point release update, but do want to get security fixes.

It did not occur to me that such a thing could be considered a misconfiguration, I've always assumed that libraries wouldn't change
enough in stable that this sort of thing would occur.

J.

--
101 things you can't have too much of : 36 - Spare video tapes.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-02-28 20:24:27 +0900, Simon Richter wrote:

Hi,

On 2/28/25 19:57, Colin Watson wrote:

But seeing two users who seem to have their systems configured this way makes me wonder what's going on.� Does anyone know of documentation somewhere that recommends configuring stable systems this way?

What is weird is that both have pin priority 500, so I wonder why the newer version isn't selected.

The package in stable is also from a point release, so point releases are available as well. My initial suspicion was "CD-ROM plus security updates", which I'd find is a somewhat understandable combination that is also broken.

I'd probably reassign to apt :>

No, according to

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098272

"apt" is fine:

I worked around it by just doing 'apt install openssh-server', but that
doesn't scale.

I'd say that this is rather a bug in unattended-upgrades.

BTW, the user still has "Debian Release: 12.6", while the current
point release is 12.9.

Also, the user says: "the unattended upgrader, which is configured to
^^^^^^^^^^^^^
only install security updates".
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Could this be a misconfiguration of unattended-upgrade?

--
Vincent Lef�vre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-02-28 16:52:57 +0100, Michael Biebl wrote:

unattended-upgrades uses this default configuration:

// "origin=Debian,codename=${distro_codename}-updates";
// "origin=Debian,codename=${distro_codename}-proposed-updates";
"origin=Debian,codename=${distro_codename},label=Debian";
"origin=Debian,codename=${distro_codename},label=Debian-Security";

Is it normal that these two lines differ only by the label?

"origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
// "o=Debian Backports,n=${distro_codename}-backports,l=Debian Backports";

So that doesn't look like a bug in unattended-upgrades.

--
Vincent Lef�vre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)