Mailing List Archive

are angle brackets around email address allowed for auto-key-locate?
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>"?

I need to ask as I have an interoperability issue with Gnome Evolution.
Evolution specifies the email with angle brackets when encrypting.

[1]: https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuratio
n-Options.html#index-auto_002dkey_002dlocate
Re: are angle brackets around email address allowed for auto-key-locate? [ In reply to ]
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. Find below our test addresses.


Salam-Shalom,

Werner



ps.
Here is our test data set. The second string is the exepcted result, if
it is NULL we can't extract a mail address from the string:

{ "Werner Koch <wk@gnupg.org>", "wk@gnupg.org" },
{ "<wk@gnupg.org>", "wk@gnupg.org" },
{ "wk@gnupg.org", "wk@gnupg.org" },
{ "wk@gnupg.org ", NULL },
{ " wk@gnupg.org", NULL },
{ "Werner Koch (test) <wk@gnupg.org>", "wk@gnupg.org" },
{ "Werner Koch <wk@gnupg.org> (test)", "wk@gnupg.org" },
{ "Werner Koch <wk@gnupg.org (test)", NULL },
{ "Werner Koch <wk@gnupg.org >", NULL },
{ "Werner Koch <wk@gnupg.org", NULL },
{ "", NULL },
{ "@", NULL },
{ "bar <>", NULL },
{ "<foo@example.org>", "foo@example.org" },
{ "<foo.@example.org>", "foo.@example.org" },
{ "<.foo.@example.org>", ".foo.@example.org" },
{ "<foo..@example.org>", "foo..@example.org" },
{ "<foo..bar@example.org>", "foo..bar@example.org" },
{ "<foo@example.org.>", NULL },
{ "<foo@example..org>", NULL },
{ "<foo@.>", NULL },
{ "<@example.org>", NULL },
{ "<foo@@example.org>", NULL },
{ "<@foo@example.org>", NULL },
{ "<foo@example.org> ()", "foo@example.org" },
{ "<fo()o@example.org> ()", "fo()o@example.org" },
{ "<fo()o@example.org> ()", "fo()o@example.org" },
{ "fo()o@example.org", NULL},
{ "Mr. Foo <foo@example.org><bar@example.net>", "foo@example.org"},
{ "Surname, Forename | company <foo@example.org>", "foo@example.org"},
/* The next one is for sure not RFC-822 correct but nevertheless
* the way gpg does it. We won't change it because the user-id
* is only rfc-822 alike and not compliant (think only of our
* utf-8 requirement). */
{ "\"<foo@example.org>\" <foo@example.net>", "foo@example.org"},

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: are angle brackets around email address allowed for auto-key-locate? [ In reply to ]
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.

Hi Werner and everyone,

thank you for your response, I was hoping that this would be possible.

On the other hand, I have experienced a behavior I could only explain
with auto-key-locate being restricted to the pure form. Maybe you can
enlighten me on this case.

I demonstrate this behavior on a system which uses the attached
configuration file gpg.conf. I tested this with GnuPG 2.1.18 and
2.2.12.

Preparation
===========
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 <edw
ard-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 is the missing angle brackets.

Can you please explain the difference? That would be of great help!

Thanks
David
Re: are angle brackets around email address allowed for auto-key-locate? [ In reply to ]
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?

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

David

[1]: https://dev.gnupg.org/
Re: are angle brackets around email address allowed for auto-key-locate? [ In reply to ]
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