Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 27 Aug 2011 20:08:46 -0500
From: "JimF" <>
To: <>
Subject: Re: .include "other_rule_group"  (a wish list item)

From: "Aleksey Cherepanov" <>

> Am I right when think that it is like to run John with the first rule
> and then to run John with the second rule (that would be pulled in)?

The way I have implented this, it is rule1 + rule2  (appended).  Actually, 
another rule set can be inserted at any location within another rule.  So 
you could have 3 or 4 rules, then an include of another rule set, then still 
have 15 other rules following.

So if this is what you had:

.include "RulesB"


You would end up with these rules:


> Maybe it would be better to run this using key like: -rules:ruleA,ruleB .
> I could imagine that it could be generalized to two operations on
> rules: append and combine.
> For instance we have two rules:
> [List.Rule:ruleA]
> A
> [List.Rule:ruleB]
> B
> where A and B are some rules.
> So ruleB appended to ruleA would look like
> A
> B
> And ruleB combined with ruleA would look like
> A B

I really like this. There are many rule sets where RulesA * RulesB would not 
be productive at all, but there are other sets where this could be SUPER 
productive.   For instance, making small rules like:


would be wonderful rules to be able to 'combine' with other rules.

> The last case could be achieved now using John in such way:
> john -ru:ruleA ... -stdout >t
> john -ru:ruleB -w:t ...
> However really it would give following combination:
> A M B
> where M is a memorization rule command.
> Maybe this could be done with key too: -ru:(ruleA+ruleB)*ruleC
> where + is used to append rule and * to combine rules. However such
> syntax needs quoting for shell that is problem like with braces quoting
> with md5_gen(n) format.

I would propose that we implement the append, using the #include syntax I 
have started.  Then add something like:

-rules=Rules1.Rules2  (or a comma, etc), to allow the combine to happen. 
Combine can be very dangerous, in the fact that it can generate millions of 
rules and there are other, many other things that need to be planned on how 
to implent. The things off the top of my head, I can see as hurdles for 
combined is:

1. huge number of combinations.   rules with 10, combined with rules of 25 
combined with rules of 120 gives 30k rules.
2. Elimination of dupe rules.
3. Reduction of rules, simple reduction, and possibly more complex 
4. Optimization of rules.  Note, if 3 and 4 are done, then elimination 
should likely be done after doing those 2.

But the concept if we can implement it properly, certainly sounds like it 
could well be a winner.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.