Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 22 Sep 2011 21:25:43 -0500
From: "JimF" <>
To: <>
Subject: Re: Request for Comments on .conf file .remove [section] processing

From: "Solar Designer" <>

> 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:

.include [rules:simple1]
.include [rules:simple2]

.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.


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.