📊 Quantitative test results for language: eng, year: 2023, size: 10K, paranoia level: 1:
🚀 Quantitative testing did not detect new false positives

What do you mean by "broken"?

And yes. The RCE rules are a pain.

@theseion

What do you mean by "broken"?

the ~ Suffix doesn't work at all for some rules, AppArmor commands are being blocked via aa-~ in unix-shell-upto3.ra. See test 932250-15

And yes. The RCE rules are a pain.

I'll open an issue on this so we can get some movement on this

the ~ Suffix doesn't work at all for some rules, AppArmor commands are being blocked via aa-~ in unix-shell-upto3.ra. See test 932250-15

Can you give me an example? Apparently, aa-~ works as intended, doesn't it?

@theseion

It doesn't, see the output below:

no_expect_ids: [932250]

aa-disable and friends aren't being blocked at all at PL-1 even though they should, it's not being excluded anywhere.

@theseion I noticed the script in unix-shell-4andup.ra is referencing a non-existent shell script (spell.sh), I tried to replace it with the one integrated in crs-toolchain but I encountered some issues. See coreruleset/crs-toolchain#248

Thanks. Let me look at some stuff :)

932250 is written in such a way that the modifiers are ignored. It will only append an approximation of the @ modifier. In that sense, what you're seeing is expected behavior. I have to look into it a bit more though to see whether this is really what we want.

The issue with 932250 should be fixed with #4231.

@theseion Done

Is go-ftw not supposed to urlencode payloads? I assumed it always encoded payloads like curl does before it sent the request, it's harder to read the payloads in their encoded variant.

@theseion Done

Is go-ftw not supposed to urlencode payloads? I assumed it always encoded payloads like curl does before it sent the request, it's harder to read the payloads in their encoded variant.

For URLs only. Data is sent verbatim.