are angle brackets around email address allowed for auto-key-locate?

Daniel Kahn Gillmor dkg at
Wed Oct 23 03:25:15 CEST 2019

On Tue 2019-10-22 06:48:44 +0200, David Hebbeker wrote:
> On Wed, 2019-10-16 at 20:26 +0200, David Hebbeker wrote:
>> On Wed, 2019-10-16 at 14:19 +0200, Werner Koch wrote:
>> > On Tue, 15 Oct 2019 22:23, David Hebbeker said:
>> > > The manual [1] says that GnuPG can automatically retrieve keys
>> > > for emails in the "user at" form. Does this exclude
>> > > emails wrapped by angle brackets like "<user at>"?
>> > 
>> > That is fine.
>> I have experienced a behavior I could only explain with auto-key-
>> locate being restricted to the pure form.
> I still have the problem described in my previous e-mail. Can it be
> that this is faulty behavior of the GnuPG?

Yes, i can confirm the same misbehavior with GnuPG 2.2.17 (though i
don't think that edward-en at is actually correctly published via
WKD, so i tested with dkg at

130 dkg at alice:/tmp/cdtemp.pipIPp$ gpg -e  -r '<dkg at>' foo.txt 
gpg: <dkg at>: skipped: No public key
gpg: foo.txt: encryption failed: No public key
2 dkg at alice:/tmp/cdtemp.pipIPp$ gpg -e  -r 'dkg at' foo.txt 
gpg: removing stale lockfile (created by 29177)
gpg: key F20691179038E5C6: "Daniel Kahn Gillmor <dkg at>" 1 new user ID
gpg: key F20691179038E5C6: "Daniel Kahn Gillmor <dkg at>" 8 new signatures
gpg: Total number processed: 1
gpg:           new user IDs: 1
gpg:         new signatures: 8
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 at>
 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 at alice:/tmp/cdtemp.pipIPp$ 

> I would create a bug report at [1] so it does not get lost. Does
> something speak against it?

Yes, in the future, please report this sort of bug directly so that we
can track the problem.  i've opened now --
please add any additional information there!

Thanks for the report,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <>

More information about the Gnupg-users mailing list