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
