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.ga22...@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
