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. 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. 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. (A & B assume Debian for brevity. In other repos changes can have even bigger/different effects, but that mail would get even longer if I would write yet more examples) Both situations deserve nagging the user in my opinion – preferably with a pointer to specific details [which apt clients do if a Release-Notes field is present in the Release file] – even if we ignore the risk of breaking existing configuration on the system. APT isn't a newspaper, but at least for me it seems wrong that the one tool people associate with getting packages has absolutely nothing to say about big events at the vendor who issues my packages. That said, while I might be able to hold my ground on A) with the remark that setting Acquire::AllowReleaseInfoChange::Codename "true" on system where you know that upgrade processes can be ignored. (setting it to true by default and letting d-i disable it for >= standard feels dirty). On B) I got serious backlash through and I might agree given that I said "grace period" myself and an apt client is basically removing that period now. Not really what I wanted… As such I would propose what Julian has hinted at already as we talked about it on IRC yesterday: 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 $ apt update N: Repository '…' changes its 'Suite' value from 'testing' to 'stable' soon. N: Repository '…' changes its 'Codename' value from 'buster' to 'bullseye' soon. N: Repository '…' changes its 'Version' value from '' to '10.0' soon. N: More information about this can be found online in the Release notes at: https://example.org/preparing-for-buster Some of these N: will be wrong depending on how you choose to refer to the repository in your sources.list – I guess we could filter with some heuristics – or not, I kinda like how that lists the options. Anyway, as N are notices they do not change the exit status of clients and might not even be shown – apt-get e.g. doesn't in non-interactive use. On 2019-07-06, the release day: $ cat buster/Release Codename: buster Suite: stable Release-Notes: https://example.org/upgrading-to-buster $ apt update # from a system with the last update call after the 2019-06-11 N: Repository '…' changed its 'Suite' value from 'testing' to 'stable'. N: More information about this can be found online in the Release notes at: https://example.org/upgrading-to-buster If you have 'debian buster' in sources.list, if you have 'debian stable': $ apt update E: Repository '…' changed its 'Codename' value from 'buster' to 'bullseye'. N: More information about this can be found online in the Release notes at: https://example.org/upgrading-to-buster N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details. N: These changes can be acknowledged interactively with 'apt' or with --allow-releaseinfo-change. If you happen to not upgrade between the announcement and the release the later case will play out exactly the same, the first one will be an error akin to the Codename case just with the Suite data instead. I have the code for it mostly written, so that seems to work and isn't too bad, but I am fairly open to feedback from everyone involved. Lets just not wait again 2 years shall we? 😉 Code will be on salsa hopefully later today, if you want to have a look or comment on specific implementation details (like field/option names, wording of messages,… …) I would encourage you to comment there and leave that bugreport for the overarching "this sucks!" and "greatest thing since sliced bread!" on the whole infrastructure as for this to work at least release, ftp & publicity team have to accept me imposing work on them (which arguably they already do anyhow, but still) and hence quickly derails if we argue about Soon/Upcoming/Next/Future- in here, too. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature