Making the case for smart cards for the average user

[Ben McGinnes]

On 7/04/2015 10:46 am, MFPA wrote:
> 
> DKG has raised a broader issue: keys exist with a UID containing an
> email address not surrounded by the conventional angle brackets,
> which causes searching for an exact match on the email address in
> the way the GnuPG man-page prescribes (by enclosing that email
> address in angle brackets) to fail. He has simply proposed that the
> absence of angle brackets in the UID should not cause the email
> address match to fail. I see that as entirely reasonable.

The function and operation you're after is reasonable, no arguments
there, my question is whether this is something which is actually a
fault with GPG or if it's your MUA.  I strongly suspect the latter and
here's why:

Using one of the more unique UIDs on my key (the 4th one) if I enter
that in the Enigmail Key Management window it returns my current key.
The same behaviour is seen with angle brackets at each end.  This
behaviour is replicated on the command line (bash) by including both
variants inside quotation marks, effectively telling bash to treat
them as part of a string.  It's only when that's not done that a
failure is produced.

*NOTE*: the 2nd and 3rd UIDs have been removed to make it clearer.
 Obviously you all know how to see those addresses.

bash4-4.3$ gpg -k "ben.mcginnes at pirate.org.au"
pub   rsa4096/0x321E4E2373590E5D 2012-07-28
uid                 [ultimate] Ben McGinnes <ben at adversary.org>
uid                 [ultimate] Ben McGinnes <ben.mcginnes at pirate.org.au>
sub   rsa3072/0x7FF2D37135C7553C 2012-07-28
sub   elg4096/0xC98BAA1862E4484D 2012-07-28

bash4-4.3$ gpg -k "<ben.mcginnes at pirate.org.au>"
pub   rsa4096/0x321E4E2373590E5D 2012-07-28
uid                 [ultimate] Ben McGinnes <ben at adversary.org>
uid                 [ultimate] Ben McGinnes <ben.mcginnes at pirate.org.au>
sub   rsa3072/0x7FF2D37135C7553C 2012-07-28
sub   elg4096/0xC98BAA1862E4484D 2012-07-28

bash4-4.3$ gpg -k ben.mcginnes at pirate.org.au
pub   rsa4096/0x321E4E2373590E5D 2012-07-28
uid                 [ultimate] Ben McGinnes <ben at adversary.org>
uid                 [ultimate] Ben McGinnes <ben.mcginnes at pirate.org.au>
sub   rsa3072/0x7FF2D37135C7553C 2012-07-28
sub   elg4096/0xC98BAA1862E4484D 2012-07-28

bash4-4.3$ gpg -k <ben.mcginnes at pirate.org.au>
bash4: syntax error near unexpected token `newline'
bash4-4.3$

An alternative character escape method drives this home:

bash4-4.3$ gpg -k \<ben.mcginnes at pirate.org.au>
bash4: syntax error near unexpected token `newline'
bash4-4.3$ gpg -k <ben.mcginnes at pirate.org.au\>
bash4: ben.mcginnes at pirate.org.au>: No such file or directory
bash4-4.3$ gpg -k \<ben.mcginnes at pirate.org.au\>
pub   rsa4096/0x321E4E2373590E5D 2012-07-28
uid                 [ultimate] Ben McGinnes <ben at adversary.org>
uid                 [ultimate] Ben McGinnes <ben.mcginnes at pirate.org.au>
sub   rsa3072/0x7FF2D37135C7553C 2012-07-28
sub   elg4096/0xC98BAA1862E4484D 2012-07-28

bash4-4.3$

Furthermore, if I put another string after the line that produced that
second error message I'll end up with a text file with that name
containing the gpg output with no output to the screen.  I'm
reasonably sure that if you do the same thing in a DOS terminal you'll
get similar or possibly identical results.  If so, then chances are
pretty good that The Bat! is doing it wrong.

> Fair enough. But they are not all equivalent. The string being
> searched for by numbers one and three does not contain opening and
> closing angle brackets, whereas the string number four is trying to
> match does include them.

Yes, that's the point, they're the 4 most likely ways a mail client
might send a UID to GPG to look for a key, that was intentional.

> And as you say, the second is not valid because < and > are special
> characters; presumably they should be escaped with a backslash, or the
> whole string enclosed in quotes as in number four.

Right, so for the MUA to match them as a string they do indeed need to
be escaped and it is precisely that behaviour which The Bat! needs to
implement for it to just work.  The way we know this is by seeing the
way Windows represents directory paths with spaces in them; that being
to enclose the string in quotation marks.

>> So I think you might find it to be something that can't be fixed
>> within GPG.
>
> I think DKG's suggestion will fix it within GPG.

I'm happy to be proven wrong on that score, but since The Bat! is the
only client this happens with, even on Windows, I'm still fairly
confident that it's the cause.


Regards,
Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150407/e30a4f16/attachment.sig>