On Mon, Sep 01, 2025 at 01:23:30PM +0200, Guillem Jover wrote:
> Hi!
Thanks a lot for starting this conversation!
> 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:
>
> * Make it possible to implement in dpkg-deb (for signing and verification)
> so all usual essential package restrictions and considerations apply
> (like no or extremely minimal dependency additions, so no XML; or
> just run-time optional ones).
Without in any way meaning to belittle the work of John Goerzen, Branden
Robinson, you yourself, and everyone else who has worked on the current
implementation of debsigs, I have to say that I approve of this.
I am not one of those people who scream and run at the mere sight of
the "XML" acronym, but the minimal dependencies and simplicity are
indeed good goals.
> * Make it possible to use only SOP/SOPV (remove all introspection of
> OpenPGP object that requires GnuPG specific interfaces).
100% behind this, too.
> * Make it possible and acceptable for uploads to the Debian archive (even
> if this ends up being not allowed, for example due to reproducibility
> concerns).
This is indeed a worthy goal, let's see what we can do about that.
It seems to me that the main problem here is that the OpenPGP signature
includes a timestamp, and the current draft-dkg-openpgp-stateless-cli-14
seems to explicitly say that the current time does not violate
the "stateless" constraints, and there is no `sop` command-line option to
specify the signing date. Of course, one could play games with setting
the current time or using `faketime` or similar... that might be
the best option for now.
> * 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).
>
> Parts of that redesign imply dropping support for current features and
> use cases, where existing users could be impacted, so the main purpose
> of this mail is to try to check whether the objectives of the redesign
> and its consequences would not negatively affect those current uses (as
> in whether current features/misdesigns would disappear which are being
> relied on).
The truth is I am much in the same boat as you here; I don't really have
much information on how signatures embedded in Debian packages are used
in the real world. So yeah, thanks for this call for info.
> We had some discussions during DebConf25 with at least Steve and Ferenc
> (both CCed), and tried to go over the redesign items, and whether things
> seemed fine to drop. These mean the following broad potential user
> impacting consequences:
>
> * Dropping support for the current XML based policy framework and
> transitioning to a simple keyring-based one, keyed on the origin
> name on the filesystem, which would imply dropping the
> optional/required/reject selectors, dropping support for selection
> based on user IDs or fingerprints (of even subkeys).
Sounds fine.
> * Whether to drop support for the policy roles, as it is not clear
> if that still makes sense. Although given that it would be trivial
> to keep, and should be easy to drop in the future, the current
> thinking is that this can stay.
This, if it is related to the keyrings/debian/role-{maint,uploader,builder}.pgp
note in debsig-verify's TODO file, also sounds fine.
> * Whether any signing policy makes sense at all, besides verified or
> not-verified against a specified keyring. It's not clear how other
> people (besides Steve and Ferenc) use the signing support? For
> example by signing all of the base distribution and their overlaid
> packages, or only signing their overlaid packages and running
> debsig-verify outside dpkg, etc.
>
> Currently, one of the main reasons for not having worked on most of
> these changes in the past has been the very minimal visibility over
> what and how this support is being used around, so it's hard to tell
> what can be dropped easily. So it would be very helpful if people that
> use debsigs and debsig-verify internally in their organizations, or
> privately, etc, would mention how it is being used and whether the
> above could break any current usage (feel free to reach out privately
> if there are security concerns involved).
>
> I'll be preparing in parallel a PoC, and an updated spec for the initial
> proposed changes (these can always be revised/changed/etc).
Some time ago I started tentatively working on a debsigs rewrite in
Rust and Python, kind of in parallel; the `debsigs --features` support and
the cmd-list, cmd-sign, cmd-verify, and i-gpg features declared there
targetted exactly that - the Python-based test suite being able to
test new partial implementations. So yeah, this might be a great time to
do two things: for me, to see whether I can actually complete those
implementations enough not to be ashamed to post the code publicly, and
I guess also for me to take a look at what you may have as a tentative spec
when you think you may have one :) (not urgent, of course; after all,
there is still the question of how people actually use those signatures)
G'luck,
Peter
--
Peter Pentchev roam@ringlet.net roam@debian.org peter@morpheusly.com
PGP key: https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Attachment:
signature.asc
Description: PGP signature