Re: debsigs - status and plans?
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. steve@einval.com
The two hard things in computing:
* naming things
* cache invalidation
* off-by-one errors -- Stig Sandbeck Mathisen
Reply to: