Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")

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

Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")

Christoph Berg-2
Package: apt
Version: 1.8.1
Severity: important

Hi,

I and #debian-devel in general were pretty surprised that our "buster"
systems couldn't properly "apt-get update" anymore today:

+ apt-get update
Get:1 http://mirror.hetzner.de/debian/packages buster InRelease [118 kB]
Get:2 http://security.debian.org/debian-security buster/updates InRelease [39.1 kB]
Get:3 http://ftp.de.debian.org/debian buster InRelease [118 kB]
Hit:4 http://apt.postgresql.org/pub/repos/apt buster-pgdg InRelease
Hit:5 http://atalia.postgresql.org/pub/repos/apt buster-pgdg-testing InRelease
Reading package lists...
E: Repository 'http://mirror.hetzner.de/debian/packages buster InRelease' changed its 'Suite' value from 'testing' to 'stable'
E: Repository 'http://security.debian.org/debian-security buster/updates InRelease' changed its 'Suite' value from 'testing' to 'stable'
E: Repository 'http://ftp.de.debian.org/debian buster InRelease' changed its 'Suite' value from 'testing' to 'stable'

For me, this killed the update process for the build chroots for
apt.postgresql.org.

I guess the same thing will happen once buster is turning oldstable,
breaking out all our stable installations out there. IMHO that's bad.

It might make sense to send a signal to people tracking suites, but if
sources.list is on a codename, it doesn't make any sense to break
systems that are totally fine.

Please consider setting Acquire::AllowReleaseInfoChange::Suite "true";

Or maybe silently do the change when running non-interactively.
Thanks.

Christoph

PS: Please document AllowReleaseInfoChange.

Reply | Threaded
Open this post in threaded view
|

Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")

Christoph Berg-2
Control: tags -1 buster sid

Re: To Debian Bug Tracking System 2019-07-07 <[hidden email]>
> Please consider setting Acquire::AllowReleaseInfoChange::Suite "true";

Fwiw, I think this needs fixing in buster, not just in unstable.

Christoph

Reply | Threaded
Open this post in threaded view
|

Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")

Julien Cristau-6
Control: severity -1 serious

On Mon, Jul 08, 2019 at 09:11:48AM +0200, Christoph Berg wrote:
> Control: tags -1 buster sid
>
> Re: To Debian Bug Tracking System 2019-07-07 <[hidden email]>
> > Please consider setting Acquire::AllowReleaseInfoChange::Suite "true";
>
> Fwiw, I think this needs fixing in buster, not just in unstable.
>
Agree.  The user experience from this is horrible.

Cheers,
Julien

Reply | Threaded
Open this post in threaded view
|

Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")

Andreas Beckmann-4
In reply to this post by Christoph Berg-2
Followup-For: Bug #931566
Control: tag -1 experimental

IMHO, the intention behind this change is good.
The implementation was completely untested. Well, it's kind of hard to
properly test such a change.
The documentation is not really helpful.

I initially thought this was caused by my rather complicated setup.
Until I experienced it on a machine installed with buster two weeks ago
and not yet "customized" by me.

Multiple errors like this:
E: Repository 'http://security-cdn.debian.org stretch/updates InRelease'
changed its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this repository
can be applied. See apt-secure(8) manpage for details.

apt-secure(8) says:

INFORMATION CHANGES
       A Release file contains beside the checksums for the files in the
       repository also general information about the repository like the
       origin, codename or version number of the release.

       This information is shown in various places so a repository owner
       should always ensure correctness. Further more user configuration
       like apt_preferences(5) can depend and make use of this
       information.
       Since version 1.5 the user must therefore explicitly confirm
       changes to signal that the user is sufficiently prepared e.g. for
       the new major release of the distribution shipped in the
       repository (as e.g. indicated by the codename).

OK, and what do I do now? How do I confirm that?

It took me some time to discover --allow-releaseinfo-change in
apt-get(8).


Andreas

PS: my apt pinning is exactly setup to prevent unwanted release
changes even if sources.list contains everything from wheezy to
experimental ;-)

Reply | Threaded
Open this post in threaded view
|

Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")

Julian Andres Klode-4
On Mon, Jul 08, 2019 at 11:19:28AM +0200, Andreas Beckmann wrote:

> Followup-For: Bug #931566
> Control: tag -1 experimental
>
> IMHO, the intention behind this change is good.
> The implementation was completely untested. Well, it's kind of hard to
> properly test such a change.
> The documentation is not really helpful.
>
> I initially thought this was caused by my rather complicated setup.
> Until I experienced it on a machine installed with buster two weeks ago
> and not yet "customized" by me.
>
> Multiple errors like this:
> E: Repository 'http://security-cdn.debian.org stretch/updates InRelease'
> changed its 'Suite' value from 'stable' to 'oldstable'
> N: This must be accepted explicitly before updates for this repository
> can be applied. See apt-secure(8) manpage for details.
>
> apt-secure(8) says:
>
> INFORMATION CHANGES
>        A Release file contains beside the checksums for the files in the
>        repository also general information about the repository like the
>        origin, codename or version number of the release.
>
>        This information is shown in various places so a repository owner
>        should always ensure correctness. Further more user configuration
>        like apt_preferences(5) can depend and make use of this
>        information.
>        Since version 1.5 the user must therefore explicitly confirm
>        changes to signal that the user is sufficiently prepared e.g. for
>        the new major release of the distribution shipped in the
>        repository (as e.g. indicated by the codename).
>
> OK, and what do I do now? How do I confirm that?
>
> It took me some time to discover --allow-releaseinfo-change in
> apt-get(8).

Please let's not discuss the manpage here. Bug#879786 has been filed for
that back in Oct 2017.

--
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#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")

Julien Cristau-6
In reply to this post by Christoph Berg-2
On Mon, Jul  8, 2019 at 11:41:55 +0200, Julian Andres Klode wrote:

> On Mon, Jul 08, 2019 at 10:17:27AM +0200, Julien Cristau wrote:
> > Control: severity -1 serious
> >
> > On Mon, Jul 08, 2019 at 09:11:48AM +0200, Christoph Berg wrote:
> > > Control: tags -1 buster sid
> > >
> > > Re: To Debian Bug Tracking System 2019-07-07 <[hidden email]>
> > > > Please consider setting Acquire::AllowReleaseInfoChange::Suite "true";
> > >
> > > Fwiw, I think this needs fixing in buster, not just in unstable.
> > >
> > Agree.  The user experience from this is horrible.
>
> We'll figure out what to do. That said, let's not rush things,
> we've got until the next release to figure out what to do and
> fix it (a fix does not help anyone affected by the change right
> now anyway).
>
> We likely do not want to allow arbitrary changes of Suite. One
> option is to introduce a new field that specifies that the Suite
> field will change to something else soon, and a field to indicate
> release notes for that change.
>
> These are important security and safety features we don't just want
> to kill because they are inconvenient. (The big reason this was
> introduced is that if you allow this to change, you can just serve
> someone an "old" oldstable repository (that still says stable) instead
> of stable, and thus starve the clients from updates).
>
How does the current behaviour fix that?  If you replay an old repo the
user is still starved from updates (how could they not be, anyway).  But
in addition now users using a legitimate repo are *also* starved from
updates, so everyone loses?

Cheers,
Julien

Reply | Threaded
Open this post in threaded view
|

Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")

Julian Andres Klode-4
On Mon, Jul 08, 2019 at 11:50:49AM +0200, Julien Cristau wrote:

> On Mon, Jul  8, 2019 at 11:41:55 +0200, Julian Andres Klode wrote:
>
> > On Mon, Jul 08, 2019 at 10:17:27AM +0200, Julien Cristau wrote:
> > > Control: severity -1 serious
> > >
> > > On Mon, Jul 08, 2019 at 09:11:48AM +0200, Christoph Berg wrote:
> > > > Control: tags -1 buster sid
> > > >
> > > > Re: To Debian Bug Tracking System 2019-07-07 <[hidden email]>
> > > > > Please consider setting Acquire::AllowReleaseInfoChange::Suite "true";
> > > >
> > > > Fwiw, I think this needs fixing in buster, not just in unstable.
> > > >
> > > Agree.  The user experience from this is horrible.
> >
> > We'll figure out what to do. That said, let's not rush things,
> > we've got until the next release to figure out what to do and
> > fix it (a fix does not help anyone affected by the change right
> > now anyway).
> >
> > We likely do not want to allow arbitrary changes of Suite. One
> > option is to introduce a new field that specifies that the Suite
> > field will change to something else soon, and a field to indicate
> > release notes for that change.
> >
> > These are important security and safety features we don't just want
> > to kill because they are inconvenient. (The big reason this was
> > introduced is that if you allow this to change, you can just serve
> > someone an "old" oldstable repository (that still says stable) instead
> > of stable, and thus starve the clients from updates).
> >
> How does the current behaviour fix that?  If you replay an old repo the
> user is still starved from updates (how could they not be, anyway).  But
> in addition now users using a legitimate repo are *also* starved from
> updates, so everyone loses?

Well, I guess I was off a bit, you replay a current oldstable - you can't
roll back to older Date values (also, Valid-Until).

Without the AllowReleaseInfo changes, all the user woudl get is a warning
that there's a mismatch, but no breakage and non-interactive systems would
thus silently not get updates. Now they'll have a failing systemd timer,
which I guess is better.

Sure, yes, in practice this means Codename changed as well. I'm not
sure there really are many repositories where only Suite can change in a
way that's security-relevant. Though, in any case, you might still end up
with broken pinning, thus it seems like a good idea to try to prevent this
as long as we don't mess up things.

Anyway, this was not my thing so I might be misrepresenting or missing
things :)

--
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#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")

Julien Cristau-6
In reply to this post by Christoph Berg-2
On Tue, Jul  9, 2019 at 15:55:02 +0200, Christoph Berg wrote:

> Re: David Kalnischkies 2019-07-09 <20190709133107.gvib2ibj6w36j447@crossbow>
> > A Release file can declare that it will "soon" change its the value of
> > a field to foo and apt clients can notify users about this so
>
> Fwiw, I think this is seriously overengineered. We can't really test
> it, and there's high chances the feature will break (itself or
> something else) more than it might fix in practise.
>
Definitely agreed.

I think overall what you're trying to do here (the whole "notify the
user they're out of date" thing) does not belong in apt.  IMO it belongs
in higher level tools that are going to heavily depend on the use case
and so there's not really a good generic answer you can come up with at
the lowest (apt) level.

Cheers,
Julien

Reply | Threaded
Open this post in threaded view
|

Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")

Christoph Berg-2
In reply to this post by Christoph Berg-2
Re: David Kalnischkies 2019-07-10 <20190710100502.yoe2umfxyiuglaw2@crossbow>
> http://deb.devuan.org/devuan/dists/stable/Release
> http://deb.devuan.org/merged/dists/stable/Release
>
> The two release pockets differ by Suite only.

Hi,

this bug is not about fixing problems that devuan and the others might
have, this is about not breaking proper Debian Buster installations.
I appreciate the efforts put into sanely handling half-broken
repositories, but I'd still like to avoid the looming shitstorm on
the stable->oldstable switch in two years.

Christoph