Re: RFC: Consequences of redesign of .deb signatures

[Guillem Jover <guillem@debian.org>]

Hi!

On Mon, 2025-09-01 at 13:41:55 +0200, Simon Josefsson wrote:
> Guillem Jover <guillem@debian.org> writes:
> >  * Make the format extensible to other signature formats or workflows
> >    (such as x509, secure-boot, IMA, etc., even if there's currently no
> >    intention to add support for any of this).
> 
> I think this is a useful goal to make sure there is no PGP specific
> assumption lurking.  The SSH signature format is low complexity, stable
> and widely implemented, so maybe supporting this would be possible?  If
> there is a framework to plug things into I may put some cycles into
> implementing SSHSIG support.  I think supporting Sigstore and Sigsum
> verification would be useful too, since I think in the coming years
> we'll look at non-transparency-signed software releases in a similar way
> that we look at non-signed software releases today.

While, I think leaving room for extension is important, I have no
immediate plans to consider implementing anything other then OpenPGP
for .deb signatures. Because this is internal to the .deb format,
and I don't see much gain currently in the added complexity of
alternative formats to do the same thing.

Although I think the design should be clear on the behavior when, say
multiple .deb signing formats/workflows are present, and how to react
to them! Or how to distinguish between a different signature format
(covering the same use case say .deb container signing with any of
OpenPGP, x509 or SSHSIG) vs a different signing workflow (say
potentially .deb container signing with OpenPGP/x509/SSHSIG vs
secure-boot for booting or IMA for filesystem metadata, etc.).

Thanks,
Guillem