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
