On Fri, Jul 12, 2019 at 04:52:36PM +0200, Julian Andres Klode wrote: > 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, 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.
Codename and Suite match for Debian and -security: http://deb.debian.org/debian/dists/buster/Release http://security.debian.org/debian-security/dists/buster/updates/Release They differ in Label (, Version) and Components only. As such I can easily hand you the Release file for Debian if you ask for security. Components has its own verify, but as both styles ("updates/main" and "main") exist in realworld scenarios we can't be that strict about it. Version is a fun one to verify as that would imply enforcing a specific version scheme. Yes, they have different keys, but while the option exists nobody really configures signed-by per sources.list entry (or Release or …) for various reasons. !33 wants to help with that, but will/does depend on the metadata to match keys entries to sources.list entries. bullseye has that "fixed" as Suite & Codename will vary for both archives, but there weren't only positive replies about that and I am not that arrogant to call all other repositories "broken" just because they don't exactly copy the choices Debian made – and even if they would they would be a candidate for the flipping. I guess Julian was thinking of the Docker example I had in a later message which is caught by having the wrong suite compared to the sources.list; but that example I included mainly to show that Debians interpretation of what Suite and Codename are might not be applicable to other repositories – for Docker, it makes perfect sense to say that "buster" is the suite they release stuff for. It is at least quite obviously not the codename for their product. > 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. Assuming I don't catch you on your first update I just have to pick a stable release (update) after the last security update you have to switch you over to never receiving security updates again (perhaps staling -security in the bounds of Valid-Until until stable has caught up with the next point release). (Me being a MITM or an evil [https-]mirror operator of course) > 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, to be clear, you think about reverting the entire thing for all fields – which is considerably more than what this bugreport is asking for. It is a valid option of course, but personally I would like to hear reasons to allowing Origin/Label to change – so far I have only seen complains about (mostly) Suite and (some) Codename [and for the record, I also got some positive replies for both, so regardless the default, I would at the very least like to retain the option] – as that jeopardises stuff like !33 as well. > > 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. I would personally consider no-upgrades a better scenario than not-for-me-upgrades, but then I wouldn't classify a failing automatic process as "stranding" given that human intervention is needed in both scenarios. > > 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. I said as much, perhaps a bit clearer a few lines below that, and I think we have consent on that – it is "just" a matter of how to achieve that. > 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 On a sidenote, it is sad that we don't update releases more often in terms of the metadata attached to them like Valid-Until which I think we should solve eventually – but that is a different issue we should work on nonetheless. > * If your machine was offline in the time between adding Future and the > new stable release, it will still be broken. Well, yes, … but that is a long time without security updates as well, so if your automatic process hasn't worked for more than a month my sympathy for breaking it "further" is limited. Anyway, as said, we could hardcode as well if it is such a pain to do the announcement dance for Debian currently. I had to update the MR anyhow as I had used the wrong code format (") {\n" vs ")\n{"). It's marked WIP as it is a) on top of Future, but could be just as easily done without it and b) has no tests included yet c) it is very hardcoded – I would like to have at least an option to disable it. It is limited to Debian by Origin as a safety measure as "testing" and "stable" are way to generic terms to give special meaning for all possible repositories, but if we consider that variant, a config option to add other origins so derivatives can opt in would be nice. Not too hard to implement, just not feeling like doing it while a complete revert is on the table (and a bit -ENOTIME, too). Best regards David Kalnischkies
signature.asc
Description: PGP signature
