Am Mon, Nov 10, 2025 at 10:58:28PM +0900, schrieb Simon Richter: > > - Nice to have: reduce today's complexity with PGP to only be in one > > file -- I think we could stop publishing Release+Release.gpg and fix > > whatever tooling breaks as a result (apt is mostly fine), relying only > > on InRelease. This would also drop the number of PGP sig operations. > > It might be possible to reuse the same signature for both Release.gpg and > InRelease. fwiw src:apt internally splits the InRelease file into a temporary Release and Release.gpg file and passes that on for verification by gpgv/sqv because that was historically easier than to reason about what part of InRelease gpgv was saying is signed after verification (--output is an addition for gpgv somewhere in the 2.x track). > > - 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. The main argument for InRelease was that Release and Release.gpg were frequently out-of-sync due to different caching and/or different mirrors answering the two requests (go read Simon McVitties reply explaining that in more detail). libapt didn't as Release files are technically optional – never mind signing them – so it requests Release before attempting Release.gpg (I am ignoring that it tries InRelease first of course), but given our HTTP/1.1 client supports pipelining (although servers and proxies might not) it could have requested both and just deal with the result. It wasn't implemented so far as pipelining is historically so buggy, that src:apt only does it if it has hashsums for the files it requests and can hence detect and potentially fix mess ups. No such thing for Release files. > We could also create an extra file, maybe "SigRelease" that uses an > extensible format that allows multiple signatures. The mentioned splitter code happily deals with multiple PGP SIGNATURE blocks, so if you can somehow massage whatever signature data you want to transport and not make gpgv/sqv barf in the process… The problem with multiple signatures in one file is that the tool(s) creating them have to know what they sign and the tool(s) verifying them have to know what was signed. Don't make that too complicated as clients like debootstrap will ideally want something available everywhere to do the verify for them and get the data that was signed – they don't tend to bend over backwards to implement it, hence why InRelease wasn't implemented in many for a LONG while. Also not that e.g. for stable you want to have multiple signatures of the same type as e.g. the Archive team and the Release team sign a release and that ideally not at the same time, so combining signatures becomes a thing. Anyway, as that thread started with a mail from Julian, you might remember this one: https://wiki.debian.org/Teams/Apt/Spec/AptSign Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature