auto-key-locate only works with raw e-mail addresses (not angle-brackets)
Open, NormalPublic

Description

Here is a demonstration of the problem, starting with an otherwise empty GNUPGHOME:

0 dkg@alice:/tmp/cdtemp.pipIPp$ gpg -e  -r 'daniel <dkg@fifthhorseman.net>' foo.txt 
gpg: daniel <dkg@fifthhorseman.net>: skipped: No public key
gpg: foo.txt: encryption failed: No public key
2 dkg@alice:/tmp/cdtemp.pipIPp$ gpg -e  -r '<dkg@fifthhorseman.net>' foo.txt 
gpg: <dkg@fifthhorseman.net>: skipped: No public key
gpg: foo.txt: encryption failed: No public key
2 dkg@alice:/tmp/cdtemp.pipIPp$ gpg -e  -r 'dkg@fifthhorseman.net' foo.txt 
gpg: key F20691179038E5C6: public key "Daniel Kahn Gillmor <dkg@fifthhorseman.net>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: no ultimately trusted keys found
gpg: B0A9B7B2D8D2CE47: There is no assurance this key belongs to the named user

sub  cv25519/B0A9B7B2D8D2CE47 2019-01-19 Daniel Kahn Gillmor <dkg@fifthhorseman.net>
 Primary key fingerprint: C4BC 2DDB 38CC E964 85EB  E9C2 F206 9117 9038 E5C6
      Subkey fingerprint: 88DE 0083 5288 C784 E73A  C940 B0A9 B7B2 D8D2 CE47

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N) y
0 dkg@alice:/tmp/cdtemp.pipIPp$

I'm seeing this with 2.2.17 in debian unstable, but discussion on gnupg-users indicates it has been a problem for many older versions as well.

Details

Version
2.2.17
dkg created this task.Wed, Oct 23, 3:24 AM

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

I was able to reproduce this behavior on a system which uses the configuration file gpg.conf (see below). I tested this with GnuPG 2.1.18 and 2.2.12.

Preparation

Use the following configuration in $GNUPGHOME:

rm msg.*
echo "hello world" > msg.txt
gpg --batch --yes --delete-keys edward-en@fsf.org

Bad Case (does not work)

gpg --always-trust -e -r "<edward-en@fsf.org>" msg.txt

	gpg: <edward-en@fsf.org>: skipped: No public key
	gpg: msg.txt: encryption failed: No public key

Good Case (works)

gpg --always-trust -e -r "edward-en@fsf.org" msg.txt

	gpg: key 9FF2194CC09A61E8: 7454 signatures not checked due to missing keys
	gpg: key 9FF2194CC09A61E8: public key "Edward, the GPG Bot <edward-en@fsf.org>" imported
	gpg: no need for a trustdb check with 'always' trust model
	gpg: Total number processed: 1
	gpg:               imported: 1
	gpg: automatically retrieved 'edward-en@fsf.org' via keyserver

Note: The only difference are the wrapping angle brackets.

According to the the test data set posted by @werner the form of the addresses should be accepted. I suggest to also adjust the part of the GnuPG manual to all designated forms.

Is this task maybe related to T1927?

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.

I am confused: The lookup described above (T4726#130327) is performed via keyserver (see output of good case). Is not that meant by remote service? Please excuse my lack of knowledge.

dkg added a comment.Thu, Oct 24, 8:41 PM

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

Due to the fact that --auto-key-locate can include a lookup to a remote service based on the recipient address, shouldn't the same rules apply? what mental model do we expect users to have here?

werner added a comment.Thu, Nov 7, 4:02 PM
-r  STRING

does a remote key lookup only if STRING is a valid addr-spec. No extraction of the addr-spec from STRING is done and thus angle brackets inhibit the use of a remote lookup. This was implemented in this way to be as much as possible backward compatible.

-r  STRING

does a remote key lookup only if STRING is a valid addr-spec. No extraction of the addr-spec from STRING is done and thus angle brackets inhibit the use of a remote lookup.

Thank you for clarifying the status quo. Fortunately this matches this part of the GnuPG manual when reading closely.

So is this the desired behaviour for the future and this issue should be closed; or shall this behaviour be changed in the midterm? I would very much appreciate a conclusive verdict on this issue.

Given that the the angle brackets are elsewhere used to indicate a search by mail address, it would be okay to allow for them in this case too (that is dkg's second example). The risk of a regression in that case is pretty low.

If there is more than just the angkle brackets we would need another option to allow for this. Otherwise too many use cases, where the uid only happens to include a mail address, would suddenly go out for a network search.

To answer your question: With the exception of case two this is desired behaviour also in the future,

werner triaged this task as Normal priority.Sat, Nov 16, 10:18 AM