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. :) > 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? > 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. 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>. 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! Thanks, Guillem
