develooper Front page | perl.perl5.porters | Postings from February 2020

Re: Backporting ac3afc4b35 (regcomp.c: make \K+ and \K* illegal.)

Thread Previous | Thread Next
Karl Williamson
February 10, 2020 18:21
Re: Backporting ac3afc4b35 (regcomp.c: make \K+ and \K* illegal.)
Message ID:
On 2/9/20 8:27 PM, demerphq wrote:
> On Sun, 9 Feb 2020 at 18:52, Ricardo Signes < 
> <>> wrote:
>     __
>     On Sat, Feb 8, 2020, at 9:06 PM, demerphq wrote:
>>     On Sun, 9 Feb 2020, 05:38 Ricardo Signes,
>>     < <>>
>>     wrote:__
>>         $ perl5.30.1 -E 'if (0) { /\K+/ } say "ok 1"'
>>         ok 1
>>         ~/code/perl5$ ./perl -I lib -E 'if (0) { /\K+/ }'
>>         \K+ is forbidden - matches null string many times in regex;
>>         marked by <-- HERE in m/\K+ <-- HERE / at -e line 1.
>>         -1 on applying this to maint.
>>     Shrug. I think this is a toy example and the test cases produce a
>>     far more dangerous outcome than this.
>     I did not mean to imply that this literal code was the actual
>     counterargument.
>     This example stands in for any very simple case in which a pattern
>     light that might be currently getting compiled, but not executed, in
>     existing code.  The problematic runtime behavior has existed
>     v5.10.0, and is not a recent regression.
> IMO this applies to nearly any security bug in the regex engine.
> For instance we are considering another bug in the security queue, which 
> would make certain patterns die that previously would not, because of 
> integer overflow. If we can't apply THIS patch, then we shouldn't 
> backport ANY security patches to the regex engines which trigger a fatal 
> exception.  The integer overflow bugs go back to the very beginning of 
> the regex engine, like Perl 1 or something, so your argument would hold 
> there as well.
> I think this rule applied excessively literally leads to absurd outcomes.
> Yves
> -- 
> perl -Mre=debug -e "/just|another|perl|hacker/"

I can't think of any legitimate purposes for quantifying any zero-length 

Using the general form of expressing them, I don't see a difference 
between any of {0,1} {0,2} {0,3} ... {0, infinity}.  They are all 
no-ops, except possibly for side effects in code blocks, as Grinnz 
pointed out on IRC.

Nor do I see any difference between {1,1} {1,2} ... {2,2} {2,3} ...
in programs that aren't in error.

So why can't we optimize all such constructs to their minimal forms. 
That would make \K+ optimize to effectively \K{1,1}, and the infinite 
loop would go away, and non-broken programs wouldn't be affected.  This 
could be done for 5.30.2, I think

We could make it fatal in blead.

And optimizing all quantifiers of zero width assertions away or to {0,1} 
in blead would prevent things like this from happening anywhere.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About