On Tue, Jul 09, 2019 at 03:31:07PM +0200, David Kalnischkies wrote: > On Mon, Jul 08, 2019 at 12:19:36PM +0200, Julian Andres Klode wrote: > > Anyway, this was not my thing so I might be misrepresenting or missing > > things :) > > First of all: I am happy that I still manage to "break the world" (FSVO > world) – in other words that is "my thing" , but I mostly forgot about > it as it was implemented two years ago at the start of the last > release cycle so that everyone would have enough time to cry at me … > worked brilliantly I guess… 😉 > > Anyway, that apt is enforcing the metadata isn't changing is a security > feature in that if you don't check an attacker can reply to a request to > foo-security with foo – perfectly signed and everything so apt has no > chance to detect this and the user believes everything is fine – even > seeing files downloaded from -security – while the user never receives > data for -security. foo has no Valid-Until header so the attacker can > keep that up for basically ever. Compared to that serving old versions > of -security itself is guarded by Valid-Until. Not serving any data has > basically the same result, but the errors involved might eventually > raise some alarm bells. So that is a good strategy to keep you from ever > installing security upgrades. This should not happen silently, as there'll be a warning that the name of the distro in the sources.list entry matches neither Codename nor Suite. We also can't do a rollback attack from current testing to an older testing either, as the Date is not allowed to roll backwards. I'm not convinced we are adding any actual security here - we should just upgrade the warning for name mismatch between sources.list and Release file to an error for that. > So, after establishing that metadata shouldn't change all the time, lets > look at the individual metadata pieces. Th recent thread on (not) using > suite/codename/version to refer to a release is not only done in > documentation and sources.list, but also in configuration for example in > apt_preferences (which apt could check theoretically) and unattended- > upgrades (which apt can't realistically check). Many of these > configuration pieces for break silently and/or run guard automatic > processes. > > People are also not very consistent in that they refer to an release in > different ways depending on the situation: While the sources.list might > refer to buster, the config for unattended upgrades could easily refer > to packages from stable to install automatically. > > > A) For a user with "debian stable" in sources.list the change of the > Codename from buster to bullseye is a giant leap which should not > be done carelessly or even automatically in the background. That's true, but leaving the user stranded without updates is not helpful either. Regarding the automatic upgrades: It seems that unattended-upgrades only considers upgrades that match the system's codename, so it won't automatically upgrade you to a new release. > > B) For a user with "debian buster" in sources.list the change of the > Suite from e.g. stable to oldstable is an important event as well; not > right at this moment as there is a grace period, but security support is > about to end and plans should be set in motion on how to deal with that. It's not an important enough change to starve them from further security updates until they acknowledge it. > 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 > they can prepare (or, for that matter help testing if they feel like > it). In exchange, if the change happens and apt knows it announced it > before it can choose to accept the change without explicit user > confirmation & I would propose enabling that for the Suite field. > > > So, lets see how that might look for Debian buster if I "will have had" > deployed a time machine: > > On 2019-06-11, perhaps a bit earlier: > > $ cat buster/Release > Codename: buster > Future-Codename: bullseye > Suite: testing > Future-Suite: stable > Future-Version: 10.0 > Future-Release-Notes: https://example.org/preparing-for-buster It turns out the only reasonable point in time to do that is during release, that is, stable would always contain Future-Suite: oldstable (and similar for others). Two reasons: * It's super annoying having to do those changes for all releases at like freeze time * If your machine was offline in the time between adding Future and the new stable release, it will still be broken. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Attachment:
signature.asc
Description: PGP signature