[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 22 Sep 2011 21:25:43 -0500
From: "JimF" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: Re: Request for Comments on .conf file .remove [section] processing
From: "Solar Designer" <solar@...nwall.com>
> Jim -
>
> On Thu, Sep 22, 2011 at 09:03:03PM -0500, JimF wrote:
>> Some of what I was wanting for remove were dealing with rulesets coming from different sources. Many of these have duplicate rules. Thus, simply including these, even in non-overlapping ways, ends up with the same rule being run multiple times. Often these overlaps are not easily found.
>
> Doesn't your code in -jumbo-7 already suppress duplicate rules in such cases?
Yes, but only if things are run.
Even in your own exmpale, if we have something like this:
[rules:simple]
.include [rules:simple1]
.include [rules:simple2]
[rules:moderate]
.include [rules:moderate1]
.include [rules:moderate2]
....
All 4 of the rules sets have been written by multpile authors. Assume moderate1 and moderate2 share numerous rules from simple1 and simple2. How are those removed to be removed, assuming that rules:simple has been run?
It may be that we make an external tool that can find duplicates. Then a user would be able to weed out dupes from his own (or collected) rulesets, and build a library that avoids this form of duplication.
Now, the way the rules reductions work, is if you run rules:simple, then a 'pre' step that happens right before the rules start, is that all duplicates which are IN the rules:simple (which happen to come from rules:simpe1 and rules:simple2) are removed. But there is no way when later we rerun our dictionary using rules:moderate, to strip out these already run rules.
But again like I mentioned, the .remove [list.rules:section] may NOT be that easy to do.
Jim.
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.
