> Converting sections of tests into plugins where some people will want to > disable the entire set due to performance, memory, or similar > constraints (i.e., Bayes tests, network tests, special functionality, > etc.) does make sense. However, converting individual (or nearly > individual) tests that are "always on" (unless the rule gets a zero > score) into plugins never has made as much sense to me.
This strikes me as right up there with plugin-izing the basic rule types like header and body. Sure, you could do it. But what is the gain in doing it? And probably more importantly, what is the performance loss in doing it? Others have suggested adding new basic rule types with plugins, which is probably not a terrible idea. But on the other hand, I'd suggest that cleaning up internal structure as necessary to make it easy to add new types internally might be a better long-term investment. I'm somewhat concerned that a willy-nilly rush to making everything a plugin might subvert any possibility of doing rule short-circuiting in an intelligent manner. A brute force method might still be possible. But it would be less than optimal, I suspect. > What if we allowed .cf files to include the eval test Perl code?? It's > a bit more radical, but it *would* be cleaner and both adding new ones > and removing old ones would be rather straightforward. Imagine, for > example, the HTML-ish eval tests (some of which have been fairly stable) > being located at the top of the 20_html_tests.cf file. > > This would give everyone, especially rule writers, a lot more > flexibility. Of course, users wouldn't be able to define them. The .cf > files already are code, this is just multiple-line code. This is along the lines I've been considering since I first started writing rules for SA. Personally, I'd much prefer that the .cf files NOT contain pure perl, for two reasons: one, it seems easy enough to be able to do horrible things with it and possibly eat the entire system and not just SA, and two, nobody except Perl people can begin to make head nor toe of the general syntax of any but the simplest constructs. (I'm sorry to say that and I'm sure it will give offence. But its true!) My thought had been along the line of defining a syntax for "multiline rules" that was fairly clean and regular, allowed the sort of parsing that rules tend to need, and DIDN'T allow all the strange and wonderous things that could be inherently evil. This admittedly is a harder go than simply deciding to include pure perl. You have to sit down and design a reasonable mini-language that most people will be able to easily understand and use, and then you have to write a translator to Perl. The first part is the hard part, of course. I have some ideas on what it should look like, but I've never really finished that thought, and I'm too swamped with other stuff at the moment to devote the couple of days to it that it requires. I'd be happy to work with others on developing something like this.
