Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 23 Sep 2011 05:04:25 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Request for Comments on .conf file .remove [section] processing

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:

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:

[List.Rules:Simple]
:
l

[List.Rules:A]
.include [List.Rules:Simple]
rule1
rule2
rule3

[List.Rules:B]
rule4
rule5

[List.Rules:Complex]
.include [List.Rules:A]
.include [List.Rules:B]
.remove [List.Rules:Simple]

you can write:

[List.Rules:Simple]
:
l

[List.Rules:A-base]
rule1
rule2
rule3

[List.Rules:A]
.include [List.Rules:Simple]
.include [List.Rules:A-base]

[List.Rules:B]
rule4
rule5

[List.Rules:Complex]
.include [List.Rules:A-base]
.include [List.Rules:B]

Yes, this might be trickier to do when those sections are spread across
several files with different maintainers, but in those cases even
.remove is no replacement for coordination between the maintainers, and
for a one-time hack a re-arrangement like my example above would work
just as well as .remove would.

Thanks,

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ