On Mon, May 17, 2021 at 02:14:09PM +0200, Guillem Jover wrote: >Hi! > >On Mon, 2021-05-17 at 12:32:52 +0100, Steve McIntyre wrote: >> I'm working on a project where inline signatures on Debian-style >> packages would be very useful, so I've started playing with debsigs >> and debsig-verify. Both packages *appear* to be maintained, with >> uploads during the Bullseye development cycle. But right now things >> don't work with gpg2, as shipped in Buster onwards (#988368, >> #988646). > >The debsig-verify one seems like a non-issue to me. :) But then both >should really be switching away from --list-packets, as that's not a >supported interface to be used by third-parties, but at the time I >looked for how the fetch the same information, it either looked painful >or not possible. I need to recheck, but what I ended up doing instead >is add support for Sequoia PGP which has better interfaces. :)
Nod, that's fair enough. :-) >> I'm also very surprised that debsigs doesn't have any >> verification code (#988369) - I'd always expect tools like this to be >> able to verify their own output! > >I guess debsig-verify has filled that role since the beginning? I suppose so, yes. I'm a firm believer in writing tools that can do the round-trip directly - I find it helps for debugging issues. :-) >> AIUI there was a plan to integrate signing more closely with dpkg. Is >> that likely to happen at some point, and if so will it be compatible >> with what's already shipped? If so, I may be able to help with the >> existing tools. Alternatively, I may need to develop a parallel >> implementation for my project, and obviously I'd like to stay >> compatible if that's possible. > >dpkg already supports running debsig-verify at unpack time. The >changes that were in "the plans" were mainly to make the signature >format acceptable to ftp-masters so that signed binaries could be >uploaded there. > >The idea has been to pack all such signatures inside a single member >(called something like sigs.tar.*), which would then indeed be >incompatible with the current format. The way I see it, the old format >would be kept supported though. Right, OK. >I guess at the same time it might be worth pondering about one of the >complaints that caused dpkg-sig to be created, which is the ability to >sign remote .debs, which would require signing digests of the ar members >instead of the members themselves, but that means needing to encode what >digest to use and how to transition to new ones, etc. > >Another problem with adding support for signed binaries to DAK is >that this would need a rethink of reproducible builds support, and >how to replay those signatures from other archives or similar. > >This was partially tracked at ><https://wiki.debian.org/Teams/Dpkg/Spec/DebSignatures>. Ah, excellent. I did some searches, but my google-fu failed today. >All this has made this a not very urgent issue to tackle, TBH. > >> Can you give me some advice here please? > >If there is no requirement of having to upload those signed binaries >into Debian, then I don't think any such format change are limiting >factors, and the current design and implementation should be enough >as is (barring specific bugs). > >If there other needs or requirements involved, I've happy to hear! Actually, I think that's it! This is a work project and we're not intending any of this to go anywhere near the main Debian archive. Your clue in #988646 has helped enormously. -- Steve McIntyre, Cambridge, UK. st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
