A little concerned now with the follow up on apachelounge's forum. Personally, if the only reason for wanting THIS RC is to get away from THAT problem, it's not going to happen.
Bottom line is the SecPcreMatchLimit & SecPcreMatchLimitRecursion will crash this module I think.
These are to keep at bay a possible DOS scenario, but I had seen it in theory but never saw a POC to prove theory could be used. That doesn't mean it can't, since I do not know for sure.
I have other concerns regarding things I am seeing. For instance, ap_get_scoreboard_worker() has changed to a wrapper function in Apache 2.3/2.4 and the call to this new wrapper, as well as the old for 2.2 are now in this RC. The problem I have is what they are looking for to know which it should be using.
#if APR_MAJOR_VERSION > 1
sbh = conn->sbh;
if (sbh == NULL) {
return DECLINED;
}
ws_record = ap_get_scoreboard_worker(sbh);
#else
ws_record = ap_get_scoreboard_worker(i, j);
#endif
everything I have ever read on list or been told is that ap_* is the Apache API, apr_* is APR. That said, why are they looking for APR 2 to decide which Apache API they are looking for. Maybe I am not seeing things further into the works, but at best this seems IMO an oversight, at worst , well I won't go there since they are still much better than I. But this should be obvious, maybe I'm wrong.
As far as mod_security, maybe 8.x of PCRE is too new and what these rules are doing requires an older version. Maybe there is no API in PCRE for adjusting these limits post PCRE 6 or 7.
So, that said, I do not think we should release these in any normal fashion. I still have not built an x64 version for 2.3. But, on the horizon is 2.3.12. We are waiting I think for APR & APR-Util releases I believe before the next version of Apache, both 2.2.18 & 2.3.12 are released. I do not want to build today and then do it again in a week. But alas, I must go to store later, will stop by the house and just do it then.
