[pcre-dev] [Bug 2562] New: a more explicit way to identify w…

Top Page
Delete this message
Author: admin
Date:  
To: pcre-dev
Subject: [pcre-dev] [Bug 2562] New: a more explicit way to identify which platforms are supported by JIT's ProtExecutableAllocator
https://bugs.exim.org/show_bug.cgi?id=2562

            Bug ID: 2562
           Summary: a more explicit way to identify which platforms are
                    supported by JIT's ProtExecutableAllocator
           Product: PCRE
           Version: N/A
          Hardware: All
                OS: All
            Status: NEW
          Severity: wishlist
          Priority: medium
         Component: Code
          Assignee: ph10@???
          Reporter: carenas@???
                CC: pcre-dev@???


Created attachment 1298
--> https://bugs.exim.org/attachment.cgi?id=1298&action=edit
proposed patch

the code for it was added as a workaround to the problems presented when
enabling JIT in a system that had SELinux enabled (as shown in bug 1749) but
while it was agreed to be a failed solution and would even degrade the security
of its users, the fact that it was still available as an option meant it was
still more broadly used than expected.

to somehow help to clarify it is meant to only be considered experimental, a
label to indicate that was added as recently as last year after reports of
problems with it being enabled broadly in both NetBSD and OpenSUSE (ex: bug
2445)

the proposed patch, makes sure that the corresponding flag (in both configure
and cmake) will be only available in the two platforms that are currently using
it (Linux and NetBSD) while it will show as "unsupported/IGNORE" in the report
after configuration is completed on all other platforms (instead of
yes|no/ON|OFF)

for cmake-gui (or cmake -LAH) the option will only be visible for the supported
platforms and if it is enabled (ex: using the corresponding -D parameter in the
commandline) then the configuration step will abort with a fatal error
indicating the configuration is not supported.

this last step is somehow more drastic, but take into consideration that the
end result otherwise will be most of the times that the configuration will
succeed and then it will fail to build as described in bug 2561, and at least
will prevent confusing reports like the one in bug 2155.

--
You are receiving this mail because:
You are on the CC list for the bug.