[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <A488967E75BA4988A0268FC7C72E8EF9@D9VGLK61>
Date: Thu, 22 Sep 2011 21:03:03 -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 10:59:01AM -0500, jfoug wrote:
: > I was going to start on this one. I would like to present some ideas, and
: > ask others if they have ideas, of how this should work, or how this work
: > should be accomplished. Please post comments or suggestions at ANY part of
: > this email, even if not a question.
:
: I am sorry to discourage you, but:
Actually, this does not 'discourage' me at all. I have started coding a little on this, and am also starting to feel like you list in this post. The .remove may not be needed, and it is NOT easy to implement, Even the rules .remove, is 'specific' code for rules, and as currently implemented it is some what of a catch-22. The rules have not been properly initialized. To properly initialize the rules, you need the config data properly loaded. i.e. both depend upon the other (to use the rules reduction code). I am not sure how to work around that shortcoming.
: I find .remove, in whatever form, more confusing than useful. So I don't
: want it implemented. But that's just me.
:
: If you choose to implement it anyway, then I think it should be oblivious
: to section types. As you recall, I similarly objected to the include
: directive doing anything special for wordlist rules. For .remove, I
: would thus object to having any specifics for external modes, etc.
:
: Yes, those limitations would make .remove even more useless than it
: would otherwise be, but at least it would be less confusing. ;-)
:
: You might manage to convince me of .remove's usefulness, but at this
: time this does not seem likely to me. My current opinion is that
: practically relevant stuff that you could do with .remove you can also
: do without it and in an easier to understand manner. For example,
: instead of:
:
I have also been investigating alternative methods vs using a .remove.
As was seen in some of my 'examples' in the extern set. Using a 'base' section, with the common code, then including the base, and simply coding just the small extra items. That certainly is a model that works, and works well, AND can
: [List.Rules:Simple]
::
: l
: Nice example clipped.
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.
This project is still smoldering in the back of my mind, but for not, it is not on the front burner.
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.
