Re: [pcre-dev] PCRE2 on Coverity Scan

2016-12-20 Thread Zoltán Herczeg
>Forgot to reply to this part -- would you prefer to keep using the >existing "pcre" project, and upload PCRE2 builds there (given PCRE1 is >reaching EOL anyhow), or keep using "pcre" for PCRE1 and request a new >project for PCRE2? Personally I wouldn't mind transferring the ownership of the

Re: [pcre-dev] PCRE2 on Coverity Scan

2016-12-20 Thread Giuseppe D'Angelo
On Tue, Dec 20, 2016 at 8:42 AM, Zoltán Herczeg wrote: >>Right, it looks like only Zoltan can add more people to it. > > I can when I will able to log in again. It seems the password recovery does > not work at the moment and I forgot the password a long time ago :) Forgot

Re: [pcre-dev] PCRE2 on Coverity Scan

2016-12-20 Thread Giuseppe D'Angelo
On Tue, Dec 20, 2016 at 8:42 AM, Zoltán Herczeg wrote: > Although "compile_bracket_matchingpath" does overwrite "current->top" > on some paths, it also contains at least one feasible path which does not > overwrite it. > > I think it expects that

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

2016-12-20 Thread admin
https://bugs.exim.org/show_bug.cgi?id=1749 Petr Pisar changed: What|Removed |Added Attachment #959 is|0 |1 obsolete|

[pcre-dev] [Bug 1749] PCRE-JITted code should be executed from non-writable memory to obey execmem SELinux restriction

2016-12-20 Thread admin
https://bugs.exim.org/show_bug.cgi?id=1749 --- Comment #23 from Petr Pisar --- No, it does not help. Change to R-- passes, subsequent change to R-X is denied. After reading Linux security/selinux/hooks.c (search for default_noexec variable), I think it simply refuses PROT_EXEC