Chaim, Ryan, Thank you for your extensive and informative responses.
It goes without saying, that juggling that many plates as you guys are doing will bring shifting priorities and areas which are neglected. This is natural and we are all only humans. Your message reminded me of a business meeting I had on Tuesday, where the bottleneck of a given process stated he and his team were so buried in work, they did not have the ressources to prepare tasks for us to help them. I get the same feeling with ModSecurity at times. Your argumentation makes perfect sense, yet things look a bit different from the user perspective. Forgive me for pointing these issues out. It's really not meant as an offence. It's more an attempt to help you understand why people like me stand at the sidelines, suffering from a bad conscience for not supporting you as you deserve. Meanwhile you fight a lonely battle feeling lost with all the tickets and requests. So Trustwave is in a similar position as Breach or Ivan Ristić on his own before. Ivan used to blame it on him picking the GPL license while you guys shifted to the Apache Licence. But this did not really change the situation. Yes, it's Apache Licenced and Trustwave only has the trademark. But in fact there is a fat Copyright by Trustwave in all the files I checked for this message. https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.0.0-dev/rules/REQUEST-42-APPLICATION-ATTACK-SQLI.conf https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/master/base_rules/modsecurity_crs_21_protocol_anomalies.conf https://github.com/SpiderLabs/ModSecurity/blob/master/apache2/modsecurity.c So Trustwave does commercial support and commercial rules and it claims the copyright. I do commercial ModSecurity support and I write rules for a living. So working on a project where somebody else claims the copyright makes me feel a bit uneasy. The Core Rules Project has been transferred to OWASP, which I think has been a good move. Unfortunately, it did not bring a vibrant community around it. Attempts to document existing rules faltered quickly. Again, it seems to me the that the core rules are still very much meant to be a Trustwave / SpiderLabs thing. Rightly so, you do almost all of the work, but it gives an exclusive feeling to the community and by exclusive I mean without us. But there is a 2nd issue, which I think is very difficult with pull requests. These are heavily optimised regexes. Honestly, I am in no position to submit a pull request to update something like this: "(?:\((?:\W*?(?:objectc(?:ategory|lass)|homedirectory|[gu]idnumber|cn)\b\W*?=|[^\w\x80-\xFF]*?[\!\&\|][^\w\x80-\xFF]*?\()|\)[^\w\x80-\xFF]*?\([^\w\x80-\xFF]*?[\!\&\|])" Disassembling it and trying to understand it, would take me the better part of an hour and I lack the deep knowledge of the real world http traffic (Honey Pot Project!) to tell legitimate from attack traffic. It looks like the 3.0.0 ruleset would be easier to read/understand. But without a more detailed description of what a given rule does and how it means to achieve this, it is very hard to contribute. In fact I have a few items, which I thought to contribute to the core rule for some time now. But then life hit me and I postponed it again and again. A lot of information is in fact available, but it is spread over too many sites. Some interlinked, some not. What I think is missing are the classic contribution / todo files what accompany other open source projects. There is developer info on www.modsecurity.org, but it is not very inviting, I think (and I think it should be) and there is nothing to be read about the plans Chaim explained in his message. I had my doubts if Apache was still a first class platform for ModSecurity and now I read for the first time black on white that nginx is now the first class passenger. But that's only a sidenote to underline the point, that it is very hard to support you, if we do not know where the train is supposed to be heading. Other things just do not seem to work. There are issues and patches which go unacknowledged. Requests for explanations or more documentation are sent in vain: https://github.com/SpiderLabs/ModSecurity/pull/840 https://github.com/SpiderLabs/ModSecurity/issues/849 http://sourceforge.net/p/mod-security/mailman/message/30918751/ I mean I am a very weak coder and it takes me ages to nail down an issue. Taking me by the hand and leading me to the next bug to tackle could actually encourage me to invest more time. Ignoring a pull request on the other hand is disappointing. But as I said, this is not meant to be a fingerpointing message. You listed all your tasks and duties and responding to a pull request, nobody else from the community seems to be interested in, does not have top priority. Given your tasklist, it is beyond imagination to fulfill all the demands from all sides. I understand that. It's just not going to change the situation of you fighting a lonely battle. There is this video about the leadership lessons of the dancing guy. Give it a shot if you do not know it. Especially the comment of the sociologist are right to the point: https://www.youtube.com/watch?v=fW8amMCVAJQ @Chaim: Your announcement of a regular message about the state and the direction of ModSec would be much appreciated. Me getting involved with certain aspects and sites, could be an option. What do you have in mind? Thank you for all your good work. It is much appreciated. So much, I built a living around Apache and ModSecurity. I no longer attend international conferences, but I still do many local talks about successful ModSecurity installations and I am still thrilled, whenever I get to write cool new rules (like yesterday, where I was able to create something really neat). This all would not be possible without you sitting down and working on ModSecurity every day. Best, Christian -- It ought to be remembered that there is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things. --- Niccolò Machiavelli _______________________________________________ Owasp-modsecurity-core-rule-set mailing list [email protected] https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
