Philipp Kern <pkern@debian.org> writes:
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.
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.