Philipp Kern <phil@philkern.de> writes: > On 11/9/25 10:51 PM, Simon Josefsson wrote: >> 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. > > I'm not sure if breaking backwards compatibility in this way is a > winning strategy. Right, but one would have to carefully design and test all of this to know what backwards compatibility is important and which of it we can handle. Do we promise that debian bookworm must be able to read InRelease files from forky? Couldn't migration happen by implementing support for Sigsum/Sigstore/etc-protected InRelease fiels in forky and then back-port to apt in trixie-updates (or a stable update release)? That approach may be seen as aggressive. If it is possible to design a solution that feels more "opt-in", and doesn't touch anything that we already do, maybe it will be easier to convince people about its safety from a more social or process point of view. Even if that technical solution ends up being more complex and have some disadvantage compared to re-using the existing InRelease file. I think we should still have all alternatives on the table to understand what we dismiss though. While Sigstore may look more production ready on the surface, from a tool and deployment perspective I think Sigsum is an easier project to start with. That's what I'm using for my software releases for about a year. I think the main conflict between them is when thinking about default choices and what that means for availability. Personally I would prefer a conservative approach for my laptop and require both Sigstore and Sigsum protection, at the cost of not upgrading software if one of the logs are down, but that trade-off is probably not universal. Or maybe it would be easier for Debian to switch to Sigstore && Sigsum as a new default, rather than picking sides and just chose one of them. Realistically, though, I suspect we aren't likely to be able to migrate to anything but opt-in for Sigstore+Sigsum protection of forky. I would be happy if even opt-in approaches would work, my attempts to add support for Sigstore+Sigsum in trixie with the 'apt-verify' package was blocked. /Simon
Attachment:
signature.asc
Description: PGP signature