On Mon, 10 Nov 2025 at 11:51:38 +0100, Simon Josefsson wrote:
- Nice to have: don't add round-trip latency fetching multiple files. This one argues for putting everyhing in one file, such as extending InRelease.
My understanding is that this is not actually the purpose of InRelease, although it's a desirable side-effect. Instead, the point of InRelease is that if the top-level metadata (Release file) is served in the same file as its signatures and during the same http transaction, then it cannot possibly be inconsistent, even during a mirror resync - whereas for Release and Release.gpg (or Release.sigstore, or whatever other signature format you might want to use), when mirroring Debian onto commodity web servers with unspecifed cache lifetimes or downloading through a caching proxy with cache behaviour similarly outside our control, there would often a window during which your mirror serves the old Release but the new Release.gpg, or vice versa. The result is that `apt update` fails with signature verification errors, even when you are not actually under attack. That's harmful from the point of view of getting updated software promptly, and also from the point of view of detecting attacks.
For the rest of the tree, a new enough version of apt can download Packages, Sources, etc. from sha256sum-based paths (content-addressed storage), so mirrors can provide continuity by offering both the old and the new Packages files under their hash-based names for a while; and the actual packages (.deb, .dsc, etc.) have uniquely versioned filenames, so they do not have the same update atomicity concerns as the metadata. The InRelease file is the only one that apt needs to be able to download from a hard-coded path, because apt can't know what hash to expect, and then that provides the "map" for downloading the rest.
If I remember correctly, Flatpak has a similar design where the signed "summary" (its equivalent of the InRelease file) is the only hard-coded filename, and is served as a single blob containing both content and signature, for much the same reason as apt's InRelease; and then everything else is downloaded from a sha256-based content-addressed filename, so that tampering by a malicious intermediary is easy to detect, and accidental mismatches on a non-malicious mirror are not possible.
smcv