pubkeys are imported despite the --no-auto-key-retrieve option
Open, Needs TriagePublic

Description

This command:

$ gpg --auto-key-locate clear,wkd --no-auto-key-retrieve --locate-key <email address>

was inspired by this guide. In the interest of checking the availability of a key without importing, I added the --no-auto-key-retrieve option. GPG ignores the option and imports the key anyway.

Details

Version
2.1.18
werner edited projects, added gnupg, FAQ; removed Bug Report.Feb 29 2020, 5:49 PM
werner added a subscriber: werner.

--auto-key-retrieves tries to find a key when verifying a signature. --locate-key however does the same as what -r does and locates a key for further use. If you don't what that, don't include a key discovery mechanism in the the auto-key-locate like (wkd in this case, which is anyway the default).

cipherpunks added a comment.EditedMar 1 2020, 5:00 PM

In my particular case, I want to find out if an email address has a publickey associated to it that is publically available anywhere. I do not want to import the key automatically. I used to use this command:

grep -qi 'search results for' <(curl -s "https://sks-keyservers.net/pks/lookup?search=$address")

but that no longer works. The WKD option is incidentally in my original post, from following an example. If I try to use all available checks:

gpg --auto-key-locate cert,pka,dane,wkd,ldap,keyserver,keyserver-URL,nodefault --locate-key $address

I get:

gpg: invalid auto-key-locate list

I'm not sure which options are incompatible, so in trying to keep it simple I tried just WKD, but coupled with a workaround to the forced import problem:

staging_dir=$(mktemp -d); torsocks gpg --homedir "$staging_dir" --no-default-keyring --keyring "$staging_dir"/throwaway_keyring.gpg --auto-key-locate clear,wkd --locate-key $address

abridged output is:

gpg: keybox '/tmp/tmp.GiJEGxGwRZ/throwaway_keyring.gpg' created
gpg: /tmp/tmp.GiJEGxGwRZ/trustdb.gpg: trustdb created
gpg: error retrieving <$address> via WKD: Operation not permitted
gpg: error reading key: Operation not permitted

That looks like another bug, no? I certainly have write permission to the temp directory.

The idea with that attempt is that if the import is dumped into a throw-away file, then it gets around the problem of being forced to import the key into my operational keyring.

werner added a comment.Mar 4 2020, 9:34 AM

keyserver-URL needs to be replaced with with a keyserver URL, like

hkps://hkps.pool.sks-keyservers.net

There are several reasons for an EPERM. For example if you are running gpg under a different UID than Dirmngr. I can't tell from the output I see. Please always use --verbose if you run into problems - this gives useful help.
The next step is to add the option "--debug ipc" to gpg so that you can view the communication between gpg and dirmngr. If that does not help add "verbose" and "debug ipc" as weel as "log-file XXX" to dirmngr.conf.

Why are you using torsocks - dirmngr has build-in Tor support.