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

Sorry, won't be able to attend today,

Last week:

• Struggled for T4713: Bug in get_best_pubkey_byname
  • Original problem of mine (newer key is not selected because the first one is not in the list of candidates) has been solved.
  • Should -r someone -e and --locate-keys someone match?
• libgcrypt ECC code clean up

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.