[PATCH] gpg: Fix regexp sanitization.

[Damien Goutte-Gattat]

On 01/19/2017 07:40 AM, John O'Meara wrote:
> I filed issue 2923

I wish I had thought to look at the bug tracker before working on the
problem... ;)


> The patch does fix the common use-case of a simple domain name
> (either not as a regex or as gnupg creates a regex), which is all the
> bug report covered. However, it does not allow more expressive uses.
> [...]My regex might then look like
> '<[^>]+[@.](sales|billing)\.example\.com>$'

Agreed. "More expressive uses" like your example are allowed by RFC
4880, but GnuPG does not support them.

I believe the original PGP did not support them either (at least
according to the user manuals I found, having never used PGP myself).

> In POSIX [...] a backslash preceding any other character is
> undefined.

Yes, and that's the root cause of the bug we're talking about: the
original code in sanitize_regexp obviously assumed the regex
implementation would treat an escaped non-special character as if it
were not escaped. Some regex packages do behave that way, but it seems
the GNU Libc's regcomp/regexec does not.


> Of course, for all of this to be generally useful, there'd also need
> to be a (non-default) mode when making a trust signature to prevent
> gnupg from escaping those characters when saving.

A possibility would be to use the --expert flag to enable such a mode.
Without that flag, we stick to the current behavior. With --expert mode
enabled, we let the user enter a regular expression of its own choosing,
and we don't touch it (no escaping and no bracketing with <[^>]+[@.] and 
 >$).

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