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

Re: debsig-verify test data contains signatures w/o debian-binary included in the signed data!


On Wed, 2021-05-05 at 12:51:18 -0500, Charles Duffy wrote:
> I notice that the test/debs/ source tree in debsig-verify includes files
> made prior to the 0.5 release, at which time the "debian-binary" file was
> not expected to be concatenated into the other data to be signed.


> ...whereas with a modern .deb file recently signed by the debsigs tool, the
> debian-binary file _must_ be concatenated into the other data (reference
> its source at
> https://gitlab.com/debsigs/debsigs/-/blob/52cb60820a1d65b87d3818d3e12945f27e88c57d/debsigs#L94
> ).
> It would be frankly less confusing to remove test data that's no longer
> relevant, though replacing it with a valid test would be better (or
> including sample data in both formats if there's backwards compatibility
> logic to be tested, though I see no such logic in the codebase).

Ah, thanks. I think I did not remove this when I took over, because I
probably wanted to preserve the policies usage at least as examples or
to base new test cases on those or similar. But you are completely
correct that having this laying around creates more confusion than the
potential benefit of keeping them, so I've just removed them.

> This came up in the context of having borrowed the test data from
> debsig-verify to use in a Go reimplementation at
> https://github.com/paultag/go-debian/blob/master/deb/sigcheck.go to ensure
> compatibility; it turns out that using this test data ensured that the
> result would _not_ be compatible with the modern format!

Hmm, it seems though that implementation is not compliant, as it
hardcodes several types, and does not use the defined policies.

In any case I'm not sure how useful is to reimplement this now, as
the debsigs infra needs to be revamped to be able to integrate it
properly into dpkg and DAK, mainly how the signatures are stored in
the .deb. I've also started pondering about switching the policy
from XML to JSON, and started some code on that direction.


Reply to: