eduar-hte
eduar-hte
I'm updating the PR to simplify it and just focus on YAJL. The changes to make libxml2 and pcre2 mandatory can be resumed when there's feedback on that.
@airween, I don't think there's anything missing to merge this PR (after limiting its scope to YAJL). I have a follow-up to build ModSecurity on mac systems running on Apple...
> @marcstern had a very good argument for the optional requirement, because what if someone doesn't want to work with JSON (or XML). With this step, we completely deprive users...
I don't disagree. As I stated in the description to this PR, the goal is not to have this integrated now, but rather to document how to update the compiler...
> But this PR definitely updates the configuration, doesn't it? Yes, but I'm not proposing integrating this PR right now, but at some point in the future. I don't think...
> Ahh, right - then please feel free to add labels on the right side of the page (now I added `[do not merge]`), which help us to discover the...
> "The modSecurity life cycle is divided into different stages. The stage that the rules are loaded is not threading safe by design. (...) Once the rules are loaded multiple...
> * [InMemoryPerProcess](https://github.com/owasp-modsecurity/ModSecurity/blob/e8db92ebb02dc349204eab1d00ea9b04e81abaf9/src/collection/backend/in_memory-per_process.h#L73) potential issues in multi-threading scenarios Created PR #3216 to try to correct this.
> * `MODSEC_MUTEX_ON_PM` define & `--enable-mutex-on-pm` configure flag The need for this *optional* lock was reviewed and confirmed not to be necessary. PR #3227 was submitted to remove it.
> * `string.h`'s `ascTime` uses `std::ctime`, which is not safe in multi-threaded contexts Created PR #3228 to address this.