[ Added Peter on CC in case he's not reading the -dpkg list ]

Hi folks,

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). 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!

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.

Can you give me some advice here please?

--
Steve McIntyre, Cambridge, UK. steve@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be
handing rope-creating factories for users to hang multiple
instances of themselves.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)