XPost: linux.debian.devel 
 From: roam@ringlet.net 
  
 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 
  
 -----BEGIN PGP SIGNATURE----- 
  
 iQIzBAABCgAdFiEELuenpRf8EkzxFcNUZR7vsCUn3xMFAmi1kH4ACgkQZR7vsCUn 
  
 [continued in next message] 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)