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 | Thread Next
Steve Hay via perl5-porters
February 10, 2020 08:52
Re: Proposed new policy and approach to handling fatal exceptions inbackports: -DFATAL_BACKPORTS_(?:DIS)?ALLOWED
Message ID:
On Mon, 10 Feb 2020 at 06:38, demerphq <> wrote:

> 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.
> [...]
> 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.
I think this is a good proposal in principle, especially in its more
conservative FATAL_BACKPORTS_ALLLOWED form, but I worry about how messy
backporting some patches might get. In the case of the two under discussion
(ac3afc4b35 and perl5-security #125) the code changes are small and
localized and easily wrapped in a new #define, but for some patches there
may be various changes strewn around several files and it could get messy,
i.e. error-prone to do, which is a worry for a maint release.

We would also need some way to test for the #define from test scripts
because most of these kinds of patches add tests to check that the fix is
working, which obviously need to be skipped if the new code isn't compiled

There is also then an extra overhead on making a maint release because we
would need to test builds with and without the new #define (whichever way
around it is done) to be sure that the manually-crafted addition of the
#define and test skips has all been done correctly, especially since it
won't be a simple matter of cherry-picking something from blead that is
already proven to be good.

My feeling is that this is something that needs further thought and
discussion before we decide whether to do it. I'm wary of jumping straight
into this in the next few weeks for 5.30.2.

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