home  bbs  files  messages ]

      ZZLI4428             linux.debian.maint.dpkg             86 messages      

[ previous | next | reply ]

[ list messages | list forums ]

  Msg # 72 of 86 on ZZLI4428, Tuesday 8-11-25, 3:02  
  From: GUILLEM JOVER  
  To: AARON RAINBOLT  
  Subj: Bug#1110172: Keys in a user's trustedkey  
 XPost: linux.debian.bugs.dist 
 From: guillem@debian.org 
  
 Hi! 
  
 On Wed, 2025-07-30 at 20:51:04 -0500, Aaron Rainbolt wrote: 
 > Package: dpkg-dev 
 > Version: 1.22.21 
 > Severity: important 
 > X-Debbugs-Cc: arraybolt3@ubuntu.com 
  
 > dpkg-source's manpage states that when verifying the OpenPGP signature on a 
 > source package that is being unpacked, the "user's trustedkeys.gpg keyring" 
 > will be used in addition to vendor-specific and official Debian keyrings. 
 > Under Bookworm, this means that a source package signed by an 
 > ultimately-trusted key in ~/.gnupg/trustedkeys.gpg will be accepted by 
 > dpkg-source. To demonstrate, on a Bookworm machine: 
  
 Right. 
  
 > On Bookworm, this will work as expected and extract the source package. 
 > However, if the above steps are executed on a Trixie machine instead, it 
 will 
 > bail out with error message "dpkg-source: error: cannot verify inline 
 > signature for ../myapp_1.0.dsc: no acceptable signature found`. I tried 
 using 
 > both the Trixie default of ECC keys and the prior Bookworm default of RSA 
 keys 
 > on Trixie, and both of them fail in identical ways. 
  
 Yes, on Debian trixie, with the OpenPGP multi-backend support, the 
 rest of the new backends do not use the trustedkeys keyring, because 
 that's GnuPG specific, and can even be in format that is non-standards 
 compliant, so it cannot even be read. 
  
 (See #1106148 for further details). 
  
 I guess the problem is that, due to the above mentioned bug report, when 
 dpkg-source grew sqv support, then it stopped at the same time loading 
 trustedkeys.{kbx,gpg} keyrings, and that is going to be the default 
 now that apt pulls it by default on most architectures. 
  
 > If dpkg-source intentionally no longer supports trusting user-provided keys 
 > when extracting source packages, this should be documented. It would be 
 much 
 > preferable to fix dpkg-source so that user-provided keys work again though. 
  
 Any such changes seemed too disruptive during the freeze, including 
 documentation fixes which invalidate translations. :/ 
  
 For the 1.23.x series (targeted at Debian forky), I've already got 
 queued changes to add support for a --signer-certs option to 
 dpkg-source (to specify user supplied keyrings in OpenPGP format), 
 a new --no-vendor-certs option to disable loading the vendor keyrings, 
 and to then warn and deprecate usage of KeyBox formatted keyrings and 
 usage of trustedkeys.{kbx,gpg} keyrings. 
  
 Thanks, 
 Guillem 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2) 

[ list messages | list forums | previous | next | reply ]

search for:

328,091 visits
(c) 1994,  bbs@darkrealms.ca