Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1179519 > unrolled thread

Bug#1059150: No longer works with signing subkeys

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1059150: No longer works with signing subkeys Steve McIntyre <steve@einval.com> - 2023-12-20 16:40 +0100
    Bug#1059150: No longer works with signing subkeys Guillem Jover <guillem@debian.org> - 2023-12-21 00:10 +0100
      Bug#1059150: No longer works with signing subkeys Guillem Jover <guillem@debian.org> - 2024-03-07 04:30 +0100

#1179519 — Bug#1059150: No longer works with signing subkeys

[Multipart message — attachments visible in raw view] — view raw

Package: debsig-verify
Version: 0.23+b2
Severity: important
Tags: patch

Hey Guillem,

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.

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.

Cheers,

Steve


-- System Information:
Debian Release: 11.8
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldoldstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-26-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debsig-verify depends on:
ii  gnupg      2.2.27-2+deb11u2
ii  gpg        2.2.27-2+deb11u2
ii  libc6      2.31-13+deb11u7
ii  libexpat1  2.2.10-2+deb11u5

debsig-verify recommends no packages.

Versions of packages debsig-verify suggests:
ii  debian-keyring  2021.09.25
ii  debsigs         0.1.25

-- no debconf information

[toc] | [next] | [standalone]

#1179581

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

[toc] | [prev] | [next] | [standalone]

#1189335

Hi!

On Wed, 2023-12-20 at 23:59:31 +0100, Guillem Jover wrote:
> On Wed, 2023-12-20 at 15:30:24 +0000, Steve McIntyre wrote:
> > 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.

I assume you have had no time to look into this, but I'd like to make
sure the above branch fixes your issue before merging, and potentially
preparing a backport for stable. :)

Thanks,
Guillem

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web