Re: [NSE] Script Dependencies Replacement for Runlevels

[Fyodor <fyodor () insecure org>]

On Mon, Nov 09, 2009 at 04:06:18PM -0700, David Fifield wrote:
> On Sun, Nov 08, 2009 at 05:45:19PM -0500, Patrick Donnelly wrote:
>
> This is a great idea. I think this patch should go in, but first, I want
> to see what people think about some changes to the interface.

I agree--this is a nice improvement!

> My question is, do we need support for strong dependencies? I'm assuming
> I'm correct in thinking that strong dependencies are a new future, and
> that weak dependencies are equivalent to runlevels. If there is a use
> case for strong dependencies I'm not against them, but I would like to
> avoid having a --script-autoadd option.

I could be missing something, but I think libraries can easily fill
the need of a "strong dependency" script with less complication.  The
first time a library function is called it can (take a mutex to insure
this isn't happening in parallel and) do the requested work for the
caller and also save any results for future callers if desired.  This
allows the script to better communicate what it wants (e.g. it can
specify parameters) and it also avoids users having to worry about
specifying scripts which are only needed because some other script
depends on them.  Users should only have to specify what they want
done (scripts) and shouldn't need to worry about their internal
implementation.

> I think people will have trouble with the distinction between "strong"
> and "weak" dependencies. How about using a name like "run_after" for
> weak dependencies?

weak_dependencies is a bit of a mouthful.  run_after sounds a bit
better.  If we only support one kind of dependencies, we could use the
"deps" keyword for them.  It is short and already has an established
meaning of "dependencies" in some circles.  It might be a bit
confusing if we're referring to the optional (weak) dependencies.  So
I'm fully open to other names.

> My bias at the moment is to just have a "depends" or "run_after"
> variable that works like the weak_dependencies you have proposed, and
> not implement strong dependencies, but I'm willing to hear potential
> uses for strong dependencies.

Yeah, I think we should be sure that strong dependencies are desirable
before adding them.

> For example,
> telnet-brute might want to run after http-userdir-enum because the
> latter can identify usernames. We could do this with runlevels by giving
> a the login-finding scripts a low runlevel, but with explicit
> dependencies every brute force script will need to know about every
> login script. I suspect this is not easy to solve from a user interface
> point of view. One idea I had was something like
>
> weak_dependencies = {"*login"}
>
> "*login" would stand for a class of scripts that would somehow signify
> that they satisfy it. The runlevel assigned to the brute script would
> have to be at least one more than the highest runlevel of any *login
> script.

That makes sense.  We might not need that just yet, but I think we
should not settle on a solution which doesn't allow us the capability
to add such a feature in the future.  I think the RPM package manager
handles this in a decent way.  You can "require" a specific package
name, or a more general functionality which other packages can provide
using the "provides" directive.

Cheers,
-F
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/