Front page | perl.perl5.porters |
Postings from February 2020
On Sun, 9 Feb 2020 at 18:52, Ricardo Signes <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>
> 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/"
Thread Previous
|
Thread Next