Philipp Kern <pkern@debian.org> writes: > Hi, > > On 11/2/25 10:32 AM, Simon Josefsson wrote: >> Philipp Kern <pkern@debian.org> writes: >> >>> In trying to retrofit this I also ran into the classic "and now I have >>> an additional file to InRelease to provide the inclusion proof" >>> problem. >> What do you think about putting all signatures in the InRelease >> file? >> The content to sign would be the same as the text in the PGP-armored >> InRelease file, which (modulo the long-standing final newline >> misbehaviour) is the same as the content of the Release file. > > Wouldn't that break existing consumption of the file by apt and we > would need a new one? Or does apt ignore bytes after the signature? Current apt frowns upon such a file, but presumably that could be fixed in forky. I suppose forky could still rely on PGP by default, but could support Sigstore/Sigsum/SSH/minisign/signify/whatever in addition to PGP, if people turn a knob. I don't know how things are implemented on the server side, or who the responsible people are -- I suppose some people may consider it less risky to introduce a new file and migrate to it, than to modify the existing InRelease files. > Similarly there is a question of what exactly to sign, with GPG's > cleartext canonicalization and all. Yes -- that should be fixed. From a specification/policy point of view, I think what should be done is simple: forget about Release+Release.gpg as obsolete, and only use InRelease files. What to sign is the YAML content with all lines ending with EOL. Right now there is ambiguity: the InRelease signatures are computed on Release content without a terminating EOL, IIRC. Or are you aware that cleartext canonicalization is used for anything but the terminating EOL? I think the only difference between unprocessed Release content and processed InRelease content is the terminating EOL, which I don't know the history for but presumably is for some historic reason. Some new policy could demand that YAML archive info ought to be formatted in a way that survives identically PGP cleartext formatting. I think that subset covers reasonable files. /Simon
Attachment:
signature.asc
Description: PGP signature