Page MenuHome GnuPG

Duplicated certificates in gpgsm pubring (2.1)
Closed, ResolvedPublic

Description

Reproducing this bug involves dirmngr's extra-certs and trusted-certs
directories. Since 070d7bf this means you have to modify files in your sysconfig
dir. Sorry for that. Turns out there is a usecase for having those in your
homedir. Debugging ;-)

To reproduce you can use Intevations email and root ca. I've attached the
exported files in a tarball.
The files were created by:
gpgsm --export 0x84F36B70 > root_ca_2010.der
gpgsm --export 0x6439087E > email_ca_2013.der
gpgsm --export 0xD2889BDB > aheinecke.der

The test signature was created by:
echo foo | gpgsm --sign --include-certs 0 -u 0xD2889BDB > testsig

Now this issue is only reproducible if you have the root_ca in trusted-certs and
the email_ca in extra-certs.

This might need root:
sysconfdir=$(gpgconf --list-dirs | grep sysconfdir | cut -f2 -d:)
mkdir -p $sysconfdir/extra-certs
mkdir -p $sysconfdir/trusted-certs
cp root_ca_2010.der $sysconfdir/trusted-certs
cp email_ca_2013.der $sysconfdir/extra-certs

Now for the test:
export GNUPGHOME=$(mktemp -d)
gpgsm --import aheinecke.der

gpgsm -k |grep -E '(ID|Subject):'

     ID: 0x76CE8F33
Subject: /CN=CA Cert Signing

Authority/OU=http:\x2f\x2fwww.cacert.org/O=Root CA/EMail=support@cacert.org

           ID: 0x72B0BD08
      Subject: /CN=The STEED Self-Signing Nonthority
           ID: 0xD2889BDB
      Subject: /CN=Andre Heinecke/O=Intevation GmbH/C=DE
           ID: 0x6439087E
      Subject: /CN=Email CA 2013/O=Intevation GmbH/C=DE
           ID: 0x84F36B70
      Subject: /CN=Root CA 2010/O=Intevation GmbH/C=DE

-> Steed and CACert come from the default file, Root CA and EMail CA were
obtained from dirmngr cache.

Now the bug:
gpgsm --verify testsig

gpgsm -k |grep -E '(ID|Subject):'

     ID: 0x76CE8F33
Subject: /CN=CA Cert Signing

Authority/OU=http:\x2f\x2fwww.cacert.org/O=Root CA/EMail=support@cacert.org

           ID: 0x72B0BD08
      Subject: /CN=The STEED Self-Signing Nonthority
           ID: 0x6439087E
      Subject: /CN=Email CA 2013/O=Intevation GmbH/C=DE
           ID: 0xD2889BDB
      Subject: /CN=Andre Heinecke/O=Intevation GmbH/C=DE
           ID: 0x84F36B70
      Subject: /CN=Root CA 2010/O=Intevation GmbH/C=DE
           ID: 0x6439087E
      Subject: /CN=Email CA 2013/O=Intevation GmbH/C=DE
           ID: 0x84F36B70
      Subject: /CN=Root CA 2010/O=Intevation GmbH/C=DE

Email CA and Root CA are now listed twice! Additional verify's do not increase that.

Details

Version
2.1.2

Event Timeline

aheinecke added subscribers: aheinecke, werner.

Except the for doubled listing, is there any other potential drawback?

I can't reproduce this problem neither in our company setup nor on a vanilla debian.

I've placed the .der files in the correct directories
/var/lib/dirmngr/extra-certs and /etc/dirmngr/trusted-certs

gpgsm --import aheinecke.der

Dirmngr output shows that the LOOKUP Issuer and Intermediate -Cert are not not
found in the dirmngr cache and they are not imported into the keyring.

This is probably another bug that hid this issue in the past.

aheinecke claimed this task.

This was fixed by:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=6619ead2cfd2abcb95b66dc70622fdeef624fb8a

using the test described in T1921 (aheinecke on Mar 10 2015, 06:13 PM / Roundup) there are no longer duplicated certificates
shown after the verify command.

Thanks!

During deployment of gnupg 2.1.3 this bug was still noticed and I can still
reproduce it with git master. -> back to chatting

I must have messed up the test in T1921 (aheinecke on Apr 08 2015, 04:36 PM / Roundup). Probably by using a different
sysconfig dir for that test. Apologies for that.

I've tested this again and again the problem was no longer visible.

So I ran the following script for some time:

    export GNUPGHOME=$(mktemp -d)
    echo 11B91B31EE09E0844D254E587A65CE5184F36B70 S > $GNUPGHOME/trustlist.txt
    echo disable-crl-checks > $GNUPGHOME/gpgsm.conf
    gpgsm --import aheinecke.der > /dev/null 2>&1
    gpgsm --verify testsig > /dev/null 2>&1
    if [ $(gpgsm -k | grep 0x84F36B70 | wc -l) = "2" ]; then
        echo bug >> bugs
        echo bug
    else
        echo nobug >> nobugs
        echo nobug
    fi
    rm -r "$GNUPGHOME"

This resulted in 85 "bug" and 31 "nobug" entries. Entries were also always in a
row. Like 10 "nobug" followed by 30 "bug" situations and then again 5 "nobug".

Probably related to system I/O.

Werner do you need me to provide more information here or can you reproduce this?

Ok now I found kbxutil and learned about ephemeral certificates (Yep reading
helps) ;-)

After the first import kbxutil lists the Root certificate three times.
Twice with ephemeral flags, once without. So gpgsm -k shows it only once. But
kbxutil --find-dups already lists those duplicates.

fpr=11:B9:1B:31:EE:09:E0:84:4D:25:4E:58:7A:65:CE:51:84:F3:6B:70 recno=5 7 8
fpr=98:2D:D4:1D:BE:91:EE:72:B3:B8:43:33:F2:21:F7:74:64:39:08:7E recno=2 4 6

Now after the verify gpgsm takes the first of those certificates and unsets the
ephemeral flag as it was used as part of a complete trustchain. (sm/certchain.c:

If the first certificate was ephemeral we now have two certificates that are not
ephemeral but are the same and gpgsm -k shows both.

My solution is to check in keydb_store_cert for ephemeral certificates and
instead of inserting those again without the ephemeral flag to remove the
ephemeral flag of the existing certificate.

It's still unclear to me though why there were three certificates (Two ephemeral
and one normal) I would have expected one ephemeral and one normal certificate.

Patch attached.

aheinecke removed a project: Restricted Project.