GPGME: looking for keys with respect to user settings
aheinecke at intevation.de
Mon Jul 9 09:42:17 CEST 2018
On Friday, July 6, 2018 9:49:56 PM CEST Wiktor Kwapisiewicz via Gnupg-devel
> I'm trying to replicate `gpg --locate-keys $EMAIL` using GPGME and have
> one question.
> I'm using `gpgme_op_keylist_ext_start` for starting the search and want
> to search using whatever is configured in gpg.conf or defaults.
You do it right. GPGME_KEYLIST_MODE_LOCATE (or an or of local and extern) uses
what is configured in auto-key-locate options. ( Be aware that since 2.1.23 WKD
is used by default)
> `gpgme_set_keylist_mode`  seems to take several flags such as
> GPGME_KEYLIST_MODE_LOCATE but it's a combination of LOCAL and EXTERN
> search (in case of e-mail address that would be WKD).
> If I don't specify mode it looks like it's always using LOCAL even if I
> explicitly set "auto-key-locate local,wkd" in .gnupg/gpg.conf
Yes. LOCAL is default. So if you don't specify a mode it just does a local
LOCAL means "--list-keys"
EXTERN means "--search"
EXTERN | LOCAL means "--locate-key"
> Is this by design that keylist_mode is not set to what is used by
> --locate-key? (that is GPGME is not using settings used by gpg)
No, I think it's a misunderstanding. To better understand what is going on I
when testing. Then you can see exactly which calls are made to GnuPG by GPGME.
> A little bit of context: I'm trying to add WKD search in mutt (in case
> someone enables explicitly encryption and doesn't have the key locally)
> but a valid question was raised, why isn't GPGME already using what the
> user has configured in their gpg.conf.
As stated above, it is. The next Version will be the first with which you can
specify "auto-key-locate" options in GPGME ( https://dev.gnupg.org/D463 )
currently GPGME does not touch auto-key-locate at all.
Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-devel