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

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

Thread Next
From:
demerphq
Date:
February 10, 2020 06:38
Subject:
Proposed new policy and approach to handling fatal exceptions inbackports: -DFATAL_BACKPORTS_(?:DIS)?ALLOWED
Message ID:
CANgJU+UPcfLSQqzXDZTQYQn6DLkAD6HDptP+rRmkeg9Q1sURog@mail.gmail.com
I believe that our approach to changes that introduce new fatal exceptions
is flawed. As far as I understand the rules we cannot introduce new fatal
exceptions. This means that a whole host of fixes for bugs in things like
the regex engine can not be backported.

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?

Anyway, it seems like there is not going to be consensus on this. But it
seems to me there is a way for us to "have our cake and eat it too". I
propose the following:

Where we find an issue that triggers segfaults, illegal reads, or infinite
loops which we solve by introducing a new exception we backport the patch
with a define guard like FATAL_BACKPORTS_ALLOWED. This would allow people
that want the protections (like $work would) can add
-DFATAL_BACKPORTS_ALLOWED to their build args.  We could also do this the
other way round, and assume people *want* such fixes but provide for a
define flag like -DFATAL_BACKPORTS_DISALLOWED, which would disable such
fixes.  I would prefer the latter, but be more than satisfied with the
former.

This would allow us to backport security measures which might involve new
fatal exceptions and give people building perl the ability to make informed
decisions about how much risk they are willing to take when upgrading an
older release. It would also IMO reduce acrimony and debate about what
constitutes a security issue.

BTW, nothing in this proposal is intended to allow backporting low
criticality fatal exceptions. I do not believe we should. But I think we
*should* be able to introduce new exceptions if they prevent serious
problems like infinite loops, or read-overruns, or whatnot.

cheers,
Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Next


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