[PATCH] gpg: Fix regexp sanitization.

[John O'Meara]

Quoth Damien Goutte-Gattat <dgouttegattat at incenp.org> on Thu, 19 Jan 2017 16:53:51 +0100:

> On 01/19/2017 07:40 AM, John O'Meara wrote:
> 
>> 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.
> 

Attached is my first pass at this. I tested with a bunch of permutations,
though possibly still not thoroughly enough. I wasn't sure what to do with
some of the original comments, so in this pass they are just removed. Since
this is now more of a converter than a sanitizer, I adjusted the name of the
function as well.

Does this look about right? Any suggestions?

Here are the tests I did (represented as c-strings):

-------------------------------------------  -----------------------------------------
input to converter                           output from converter
-------------------------------------------  -----------------------------------------
"<[^]+[@.](a|b)\\.example\\.com>$"           "<[^]+[@.](a|b)\\.example\\.com>$"
"ex\\a\\mple\\.com"                          "example\\.com"
"test{ing}"                                  "test\\{ing}"
"test\\{ing}"                                "test\\{ing}"
"test\\\\ing"                                "test\\\\ing"
"testing\\$"                                 "testing\\$"
"this is [a\\range]"                         "this is [a\\range]"
"[ran\\ge$] at start"                        "[ran\\ge$] at start"
"close in []ran\\ge]"                        "close in []ran\\ge]"
"close in neg [^]ran\\ge]"                   "close in neg [^]ran\\ge]"
"\\a\\b\\(\\|\\)\\.\\{{\\\\\\*\\+\\?\\^\\$"  "ab\\(\\|\\)\\.\\{\\{\\\\\\*\\+\\?\\^\\$"
-------------------------------------------  -----------------------------------------


>> 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 
>  >$).

Attached also is a pass at allowing the --expert flag to put a raw regexp in
the trust sig.

Is using the strdup here ok, or should I instead assign p to *regex, not free
p, print the newline, and return early?


Thanks in advance for your comments.
-- John O'Meara
-------------- next part --------------
A non-text attachment was scrubbed...
Name: regexp_convert.patch
Type: text/x-diff
Size: 4843 bytes
Desc: not available
URL: </pipermail/attachments/20170128/552ede0f/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: expert_edit_regexp.patch
Type: text/x-diff
Size: 1278 bytes
Desc: not available
URL: </pipermail/attachments/20170128/552ede0f/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: </pipermail/attachments/20170128/552ede0f/attachment.sig>