@werner, are you saying that gpgme is not fully supported for use with gpg 1.4?

@werner, you seem to be saying that -r does not imply "key lookups on remote services". Is that correct?

There is a growing bit of popular lore in the GnuPG community that "when keyserver operations fail, you solve that problem with killall dirmngr." I believe this suggestion is potentially damaging (the long-running daemon may be in the middle of operations for a client that you don't know about), but i suspect it is circulating as advice because it resolves the situation outlined in this ticket. For whatever ephemeral reason, dirmngr gets stuck, and fails to notice that this situation has resolved itself.

In T4726#130341, @werner wrote:

This is a misunderstanding. The extraction of mail addresses is only doe for key lookups on remote services. Thus the -r case is as intended.

This is a misunderstanding. The extraction of mail addresses is only doe for key lookups on remote services. Thus the -r case is as intended.

That seems to be gpg 1.4 which we do not fully support.

Sure: https://gitlab.com/sequoia-pgp/openpgp-interoperability-test-suite/blob/master/src/gnupg.rs#L70

Is this task maybe related to T1927?

Thank you @dkg for creating the bug report! I would like to glean the following information from the above mentioned discussion.

@justus can you provide an example of the gpgme code you're using that generates this weirdness?

https://twitter.com/charleslewisni4/status/1051021429637025792?s=20

On July, 19th, @werner wrote:

You need to wait a bit more.

Still unresolved...

Or... it could be a feature, not bug, so that failure of -e -r someone can be examined by --locate-keys someone.

Let me clarify the point.

GnuPG ships a non-PKI certificate, specifically to authenticate hkps.pool.sks-keyservers.net. Now due to an implementation detail, this has been shown to potentially lead to authentication of other domains by this certificate, if a maintainer changes the default keyserver via the DIRMNGR_DEFAULT_KEYSERVER variable in configure.ac. Now arguably, this variable isn't exposed via ./configure, so it's not "officially" configurable - but evidently maintainers do want to change it. A trivial one-line patch was supplied to change the unintended and potentially security-problematic behavior into the (I believe) obviously intended one.

I think that we should apply further change:

diff --git a/g10/getkey.c b/g10/getkey.c
index 077209415..1c337149c 100644
--- a/g10/getkey.c
+++ b/g10/getkey.c
@@ -1369,7 +1369,7 @@ get_best_pubkey_byname (ctrl_t ctrl, enum get_pubkey_modes mode,
     *retctx = NULL;

I found more wrong cases of get_best_pubkey_byname.
For ranking results,
(1) It may return non-encryption primary key as the most relevant key, when its validity is higher.
(2) It may not select encryption primary key even if its creation time is newer.

I also think this makes the most sense.

In my opinion, --locate-key should locate encryption key.

@gniibe oh, I see thanks for pointing out precisely main the problem. I will check the hardware supply chain RoHS 2002/95/EC

There are some problems with the definition of --locate-key. Further discussion required.