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

Re: Proposed new policy and approach to handling fatal exceptions inbackports: -DFATAL_BACKPORTS_(?:DIS)?ALLOWED

Thread Previous
From:
demerphq
Date:
February 10, 2020 15:25
Subject:
Re: Proposed new policy and approach to handling fatal exceptions inbackports: -DFATAL_BACKPORTS_(?:DIS)?ALLOWED
Message ID:
CANgJU+X2Tpe4MQx-U=sno5hvEwL5rcB6MvHiu7rk+uax1bSgAg@mail.gmail.com
On Mon, 10 Feb 2020, 22:12 demerphq, <demerphq@gmail.com> wrote:

>
>
> On Mon, 10 Feb 2020, 21:03 Ricardo Signes, <perl.p5p@rjbs.manxome.org>
> wrote:
>
>> On Mon, Feb 10, 2020, at 1:37 AM, demerphq wrote:
>>
>> I personally find this absurd. In one case we are arguing that making a
>> regexp construct that can infinite loop die cannot be backported because it
>> introduces a new fatal exception. There is some suggestion that making it
>> generate a different, existing error message, "saves the backport". I find
>> this absurd too. Why should a less useful message be ok, but a more
>> informative one not be?
>>
>>
>> You are omitting an important part of my objection:
>>
>> It introduces a new *compile time *exception that would affect programs
>> not affected by the existing *runtime* exception.
>>
>> This isn't swapping in a better error message.  This is making more
>> programs die, including ones that currently run without error.
>>
>
> It is clear to me you and I arent going to agree about this, which is why
> I'm try I'm trying to figure out a solution that works for both of us.
>

Argh hit send too soon.

I dont think the compile time argument holds water. Some bugs are best
handled at compile time.  I consider this one of the most serious regex
engine bugs I have looked into. It infinite loops in a way I have never
seen before, possibly even in a way that alarm can't interdict. (I havent
check but when I tested this bug in 5.30.1 the output was extremely
unusual.)

I created KEEPS, and when I did so I was unable to find a case where it
caused a problem. Had I found this case it absolutely would have died when
combined with a quantified. I consider myself about as qualified as anybody
to assess this and frankly it scares me. I consider it very close to a CVE
level issue.

You seem to be willing to expose this bug to the public without
backporting. I am very much of a different mind.

For me the risk vastly outweighs the chance that someone has code with \K+
in it that produces warnings. I think that is very unlikely so I think
frankly "thou doeth protest too much". But at the same time I respect that
reasonable people can disagree about things like this. So I want to find a
solution that allows both our view. Which is why I posted this thread.

Lastly from the dialog I have seen on this subject the rule isnt "no new
/compile/ time exceptions" it is "no new fatal exceptions". This view seems
sufficiently widely held that Steve asked me if it was possible to change
the error reported. You are now arguing that it is only because it is a
compile time that you object. But I dont think that is what the rule says,
and I still think that interpretation is essentially unsound. For instance
take integer overflow, if it was possible to construct a pattern that
segfaulted on first execution of the pattern /before it did anything/, then
imo it would be reasonable to have it die during regex compilation,
especially if said check was more performant than catching it at run time.

But again, I respect that you see this differently. Which is why I want to
solve this philosophical difference by letting us both get what we think is
right. Surely that is best for all concerned?

Yves

>

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About