On Mon, 10 Feb 2020 at 06:38, demerphq <demerphq@gmail.com> 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 in. 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