Front page | perl.perl5.porters |
Postings from February 2020
Re: Backporting ac3afc4b35 (regcomp.c: make \K+ and \K* illegal.)
Thread Previous
|
Thread Next
From:
Karl Williamson
Date:
February 10, 2020 18:21
Subject:
Re: Backporting ac3afc4b35 (regcomp.c: make \K+ and \K* illegal.)
Message ID:
acc058a9-fe65-f63f-846b-eb1282a3a708@khwilliamson.com
On 2/9/20 8:27 PM, demerphq wrote:
> On Sun, 9 Feb 2020 at 18:52, Ricardo Signes <perl.p5p@rjbs.manxome.org
> <mailto:perl.p5p@rjbs.manxome.org>> wrote:
>
> __
> On Sat, Feb 8, 2020, at 9:06 PM, demerphq wrote:
>>
>> On Sun, 9 Feb 2020, 05:38 Ricardo Signes,
>> <perl.p5p@rjbs.manxome.org <mailto:perl.p5p@rjbs.manxome.org>>
>> 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
assertion.
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