`gpg --recv-keys` works, but `auto-key-retrieve` does not

Question

I am trying to verify the file

https://clientupdates.dropboxstatic.com/dbx-releng/client/dropbox-lnx.x86_64-108.4.453.tar.gz

using the signature provided here:

https://clientupdates.dropboxstatic.com/dbx-releng/client/dropbox-lnx.x86_64-108.4.453.tar.gz.asc

I am using the following command:

gpg --verify dropbox-lnx.x86_64-108.4.453.tar.gz.asc

which results in the following output:

gpg: assuming signed data in 'dropbox-lnx.x86_64-108.4.453.tar.gz'
gpg: Signature made Tue 20 Oct 2020 10:53:17 PM CEST
gpg:                using RSA key FC918B335044912E
gpg: Can't check signature: No public key

My GPG-configuration in ~/.gnupg/gpg.conf looks like this:

keyserver keyserver.ubuntu.com
auto-key-retrieve

with emphasis on the auto-key-retrieve. This setup works, as in: I successfully verified files with it before, even if I didn't have the public key in question; it was retrieved as expected during verification.

gpg --search-keys FC918B335044912E also shows that the key can be found on the keyserver I'm using. I can also gpg --recv-keys it, after which the verification obviously works.

My question, which might stem from a misunderstanding of the operations of gpg is: Why can I manually get the key in question, but not automatically using auto-key-retrieve, even though I know it works with other keys?

Answer 1

Having dug a bit deeper into this, I think I can now at least partly answer this myself. Any supplemental information is of course still welcome. :)

The reason is probably the fact that the given signature does not contain the fingerprint of the key, but only the key ID. You can see this for example with gpg --list-packets. For the signature in question you get

:signature packet: algo 1, keyid FC918B335044912E
    version 4, created 1603227197, md5len 0, sigclass 0x00
    digest algo 8, begin of digest fd b9
    hashed subpkt 2 len 4 (sig created 2020-10-20)
    subpkt 16 len 8 (issuer key ID FC918B335044912E)
    data: [2046 bits]

For another signature, where auto-key-retrieve worked, it looked like this:

:signature packet: algo 1, keyid BCAA30EA9C0D5763
    version 4, created 1543944543, md5len 0, sigclass 0x00
    digest algo 10, begin of digest 84 51
    hashed subpkt 33 len 21 (issuer fpr v4 1A4E8B7277C42E53DBA9C7B9BCAA30EA9C0D5763)
    hashed subpkt 2 len 4 (sig created 2018-12-04)
    subpkt 16 len 8 (issuer key ID BCAA30EA9C0D5763)
    data: [2046 bits]

with emphasis on the line

    hashed subpkt 33 len 21 (issuer fpr v4 1A4E8B7277C42E53DBA9C7B9BCAA30EA9C0D5763)

man gpg clearly states in the section about auto-key-retrieve:

The order of methods tried to lookup the key is:

[...]

5. If any keyserver is configured and the Issuer Fingerprint is part of the signature (since GnuPG 2.1.16), the configured keyservers are tried.

(Emphasis mine.)

--recv-keys on the other hand does look up by key ID, as well.

---

Sidenote: The Dropbox key not having the fingerprint is weird. Part of the reason for removing key ID lookup, given in this commit from 2019-07-05, was that even then the fingerprint was apparently included in signatures by default for a long time. The Dropbox signature is from 2020-10-20. Get your act together, Dropbox! xP