December monthly meeting agenda

[spartantri]

• CRS is about to win an award; this will bring some media coverage hopefully. We should use that new momentum
• Handling of case (?:in)?sensitive items (see below for additional infos)
• We need a plan to reduce open issues. The way it is now gives a bad impression
• PR Update date and add badges #978 : Update date and add badges
• PR Make travis tests fail if Apache can't load rules #977 : Travis: fail if apache fails
• PR 933131 checks should be case -insensitive #970 : 933131: insensitive tests
• PR Classic SQL injection probing rule split 942370 #957 : 942370 : rule split
• PR Add configurable timestamp format to our ftw integration #953 : ftw: configurable time stamp format
• PR for the serilize object injection, it should be 933170 instead of 933150 #926 - fix for 920390, and also need to add setvar:tx.total_arg_length=10"… #949 : FTW test PRs by @azhao155
• PR duplicated header bypax fix and chunk support #905 : fix for duplicated header bypass
• PR Working Dokuwiki and Nextcloud rulesets. #899 : Rule exclusion packages for dokuwiki and nextcloud (no progres on the side of the contributor)
• PR Command substitution backquoted version support #896 : Command substitution backquoted version support
• PR Create REQUEST-944-APPLICATION-ATTACK-JAVA.conf #881 : REQUEST-944-APPLICATION-ATTACK-JAVA.conf Feature Request

Case sensitive items (additional infos)

There are rules with different approaches

• Ignore cases by converting all to lowercase/uppercase in a transform (t:lowercase)
• Ignore cases by using case insensitive regex (?i)
• Case sensitive rules using all uppercase [good for http methods bad for most other stuff] (?:GET|POST)
• Case sensitive rules using regex with both cases (?:[eEiIoOuUyY]acute)

• Which one is faster?
• Benchmarks?
• Which one to use on which circumstance

It maybe easier to use t:lowercase and convert all the regex to lowercase and add a warning in CONTRIBUTING.md

[csanders-git]

i'm actually not sure about this. My gut says that the transform will be faster but if the regex engine is already booted up for something different the performance is probably negligible

[dune73]

It's probably worth to test in detail before we chance anything.

[fgsch]

My gut feeling says the opposite, the regexp should be faster or equal.

Also there is no need to pre-convert the whole input to lowercase if it's not going to match further down the line. For large inputs this might be considerable.

It'd be great to see some benchmarks though.

[lifeforms]

Handling of case (?:in)?sensitive items - To set a standard for future development, we need to know which way has better performance. @spartantri is going to try to do some benchmarks on Apache, so we can revisit the issue next month.

[lifeforms]

Open issues: Yeah, there are many open issues.. All reviewers should try to look at their assigned issues if they can. Many new PRs are about the test suite, which is not working yet for everyone. These issues fortunately seem small. They are assigned to @csanders-git.