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

Re: debsigs - status and plans?


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

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!


Reply to: