Operator @rx has different flags in two engines

[airween]

Describe the bug

It seems like the @rx operator has a different behavior in two engines (mod_security2 and libmodsecurity3)

mod_security2 has these PCRE flags:

PCRE2, PCRE

libmodsecurity3 has these ones:

PCRE2, PCRE

To Reproduce

coreruleset/coreruleset#3277

We should discuss:

• do we want to resolve this issue?
• how?

[airween]

I think this is a good idea, I mean add a build flag to libmodsecurity3 (mod_security2 is not affected) which changes the flag, and not in the next release but after that we make it mandatory (and we can add an optional build flag to keep the old (current) one).

[marcstern]

PCRE2_DOTALL & PCRE2_DOLLAR_ENDONLY look the right way for me as we need to check multiline ARGS

[fzipi]

@airween I opened #3600 implementing this using the build-flag approach you proposed, mirroring what Coraza shipped in corazawaf/coraza#876 (--enable-regex-dollar-endonly, off by default). Only @rx/@rxGlobal are affected; other operators keep their current regex flags. Would appreciate a look when you have a chance.

[airween]

@fzipi thanks both for put this again to the table and also for the PR (#3600).

Let me review the whole situation. In 2024's CRS retreat we discussed about this with @M4tteoP, but I have a memory that we agreed libmodsecurity3's behavior is the correct (but may be I'm wrong...). After a quick review now I think mod_security2's behavior should be the reference.

[M4tteoP]

hey, I'm checking coraza PR and there we moved from libmodsec behavior to v2. The key point is that we should not always run regexes with multiline on, which might lead to FPs and lose some performance. So you are right, I get that the mod_security2's behavior should be the reference and Felipe PR looks aligned with this reasoning

[fzipi]

That's what I understood. 😄