[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debsigs - status and plans?

On Mon, May 17, 2021 at 02:14:09PM +0200, Guillem Jover wrote:
>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

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: