I am trying to automate the compilation of the newest GCC on my dev machine, and I'd like to automatically verify the signature of the tarball too. However, I can't get gpg --auto-key-retrieve to work:

gcc# gpg --auto-key-retrieve --verify gcc-11.1.0.tar.xz.sig tarballs/gcc-11.1.0.tar.xz
gpg: Signature made Tue Apr 27 12:39:44 2021 CEST
gpg:                using RSA key 6C35B99309B5FA62
gpg: Can't check signature: No public key

If I manually retrieve the key, it works just fine (and the gpg --verify succeeds as well):

gcc# gpg --recv-keys 6C35B99309B5FA62
gpg: /home/user/.gnupg/trustdb.gpg: trustdb created
gpg: key 6C35B99309B5FA62: public key "..." imported
gpg: Total number processed: 1
gpg:               imported: 1

(default keyserver used in the above is https://keys.openpgp.org:443)

I've tried:

  • --keyserver-options auto-key-retrieve,
  • manually specifying the server,
  • auto-key-locate (though I've learned this has nothing to do with my use case).

What am I doing wrong?

I'm running gpg version 2.2.19 on Ubuntu 20.04.2 and working on files originally from http://ftp.gnu.org/gnu/gcc/gcc-11.1.0/.

1 Answer 1


The signature was made using an old GnuPG version which doesn't add the "issuer fingerprint" subpacket. Without this extension, PGP signatures contain only the 64-bit "key ID" of the signer's key (i.e. last 64 bits of the whole SHA-1 fingerprint), which is not enough to unambiguously determine the correct key to validate against.

Previous GnuPG versions used to simply search the keyserver for the key ID (like you did) and download whichever result they found. However, it is now practical to create PGP keys with chosen key IDs – 32-bit 'short' IDs are trivial, 64-bit 'long' IDs are still relatively hard but nowhere near impossible. (For example, creating data whose SHA hashes have a chosen 64-bit suffix is literally how they 'mine' a block in Bitcoin.)

So in order to to guard against various attacks (such as someone publishing a malformed key with a ID matching that of a legitimate developer's), GnuPG no longer enables 'auto-key-retrieve' for signatures which don't indicate the full 160-bit key fingerprint.

$ gpg --list-packets < gcc-11.1.0.tar.gz.sig
# off=0 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid 6C35B99309B5FA62
        version 4, created 1619519994, md5len 0, sigclass 0x00
        digest algo 2, begin of digest ae b1
        hashed subpkt 2 len 4 (sig created 2021-04-27)
        subpkt 16 len 8 (issuer key ID 6C35B99309B5FA62)
        data: [4095 bits]
$ gpg --detach-sign test
$ gpg --list-packets < test.sig
# off=0 ctb=88 tag=2 hlen=2 plen=117
:signature packet: algo 22, keyid 11319E694F0B2ABB
        version 4, created 1622789848, md5len 0, sigclass 0x00
        digest algo 9, begin of digest ed 7f
        hashed subpkt 33 len 21 (issuer fpr v4 19E6940AE6C3EDC5D6A7684211319E694F0B2ABB)
        hashed subpkt 2 len 4 (sig created 2021-06-04)
        subpkt 16 len 8 (issuer key ID 11319E694F0B2ABB)
        data: [255 bits]
        data: [256 bits]
  • Thanks a lot for the detailed insight! What is the recommended solution? Simply use a newer gpg for signing? Would that break signature checking on older gpgs? Is there perhaps an option to ask for the full fingerprint in the signature even on older gpgs?
    – Irfy
    Jun 4, 2021 at 10:25
  • 1
    Yes. No, it wouldn't. No, there isn't.
    – user1686
    Jun 4, 2021 at 10:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.