XPost: linux.debian.devel 
 From: guillem@debian.org 
  
 Hi! 
  
 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). 
  * Make it possible to use only SOP/SOPV (remove all introspection of 
    OpenPGP object that requires GnuPG specific interfaces). 
  * 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). 
  * 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). 
  
 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). 
  
   * 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. 
  
   * 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). 
  
 Thanks, 
 Guillem 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)