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@example.com" form. Does this exclude
>> > > emails wrapped by angle brackets like "<user@example.com>"?
>> >
>> > 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@fsf.org is actually correctly published via
WKD, so i tested with dkg@fifthhorseman.net):
130 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: removing stale lockfile (created by 29177)
gpg: key F20691179038E5C6: "Daniel Kahn Gillmor <dkg@fifthhorseman.net>" 1 new user ID
gpg: key F20691179038E5C6: "Daniel Kahn Gillmor <dkg@fifthhorseman.net>" 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@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 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
https://dev.gnupg.org/T4726 now --
please add any additional information there!
Thanks for the report,
--dkg