Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")
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 <[🔎] 20190707183910.GA22754@msg.df7cb.de>
> > > > > 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 to: