Hi!
On Wed, 2023-12-20 at 15:30:24 +0000, Steve McIntyre wrote:
> Package: debsig-verify
> Version: 0.23+b2
> Severity: important
> Tags: patch
> Updating our derived distro from bullseye to bookworm, we've moved on
> from 0.23 to 0.28. We're using subkeys for signing our debs, and that
> no longer works. I can see that the change you've made to no longer
> fall back if a fingerprint doesn't match
> (849d9633ebf809398c848821c603148ae0470278) has broken this.
Ouch, I've been increasingly unhappy with the whole policy thing,
because it was not functioning as documented, fixing it to do so has
broken multiple use cases, it seems like unnecessary complexity and in
a way trying to reimplement some of the checks that should be done by
the OpenPGP implementation, and it is getting in the way of adding
other OpenPGP backends due to the insistence of tying the signature
issuer fingerprint with the policy to apply, which means the primary
certificate fingerprint cannot be used as would perhaps be usually
expected.
I recorded part of this in the TODO, and I had in mind asking you
about how you use this as part of the redesign work, but I'll leave
that for a later point. :)
> Here's a patch that I've added locally on top of 0.28 to also attempt
> to match subkey fingerprints. This passes tests here and makes subkeys
> work for us again.
Thanks for tracking this and providing a patch!
> diff --git a/src/openpgp-gpg.c b/src/openpgp-gpg.c
> index 4c29b7f..97ec3a4 100644
> --- a/src/openpgp-gpg.c
> +++ b/src/openpgp-gpg.c
> @@ -241,6 +242,7 @@ gpg_getKeyID(const char *keyring, const char *match_id)
> continue;
> if (strcmp(uid, match_id) != 0) {
> free(uid);
> + state = KEYID_SUB;
> continue;
> }
> free(uid);
I think the problem with this is that if the first uid does not match,
then it will then switch to looking for a new fingerprint line, which
might then omit some valid uids.
I've prepared a change based on this at:
https://git.hadrons.org/cgit/debian/dpkg/debsig-verify.git/log/?h=pu/openpgp-subkey
With the assumption that one would define the policy and keyrings
paths based on the subkey fingerprint and not the primary public
certificate fingerprint, because otherwise some of the other matches
cannot easily match, such as uid-based ones. But wanted to check with
you whether that's the case before merging. Otherwise I can try to see
how to support all the various cases.
(For example I think the current code might break if the public
certificate can sign, but it has a signing subkey too, and the
signature issuer is the public certificate. :/)
Thanks,
Guillem
