Re: RFC: Consequences of redesign of .deb signatures
Hi!
On Mon, 2025-09-01 at 14:34:33 -0500, Steven Robbins wrote:
> > The current support for .deb signatures (as implemented by debsigs
> > and debsig-verify, which dpkg can be configured to call by disabling
> > the «no-debsig» configuration option), has multiple limitations.
> >
> > The following are the main redesign objectives, which try to fix
> > those limitations: [...]
>
> I'm not deeply invested in signatures, just an average Debian Developer that
> uses them quite often.
Ah, if you are using .deb signatures, then I'm interested to know how
you use them! Whether you have configured a specific debsig-verify
policy, how you verify the .debs, while also pulling from Debian (which
does not sign the .debs), etc.
But from your wording, I'm not entirely sure whether you do use .deb
signing, or perhaps you are thinking about signing the repos metadata,
and the .dsc, .changes and .buildinfo files instead?
> I got immediately lost in the transition from "there
> are limitations" to a list of detailed design proposals.
>
> Is there a summary of the limitations somewhere at a level of "just a user"
> could follow? All I'm really hoping to do is follow the design discussion at
> a "how does it impact me" level.
Sorry, I didn't want to get into more detail, as I assumed that this
would be clear for people already using the debsig-verify support,
and it seemed like a distraction at this point.
As a quick summary, there are two main parts of this redesign, one is
on the format, which only affects the users in the sense of requiring
tooling that understands it, but otherwise should be transparent (I
didn't really go into any detail here, because it does not currently
seem relevant).
The other part is that the current support in debsig-verify relies on
an XML based policy framework to decide what to do with the signatures.
Using XML is problematic in itself because it means implementing this
in dpkg-deb would require pulling such library into the essential set,
which I'd not really be thrilled about. The other problem is that the
current policy seems too complex for what it is trying to do (requires
matching based on the signature signer's fingerprint, or signer's email,
both of which require introspecting on the signature, before even
verification has started, and also on the signer roles), and imposes
implementation constraints on what signing and signature introspection
is required, which currently ties the implementation to GnuPG, and
even then that is fragile and broken on edge cases (such as the
signature being made with a subkey, and then keying on the main key,
etc). Instead of just passing a keyring and checking whether the .deb
verifies or not.
So the main focus of this RFC was to canvas how people use the .deb
signing to see whether dropping the entire policy framework in its
current form is viable, so that the implementation and the mental
model for all this can be substantially simplified.
(Not sure if that has clarified things, though. :)
Thanks,
Guillem
Reply to: