Re: Script force

[Martin Holst Swende <martin () swende se>]

Hi,

On 12/04/2011 10:00 AM, Patrick Donnelly wrote:
> With that said, I have a suggestion. The '+' should be a prefix to a
> pattern. It should not be a prefix to a filename, category, or boolean
> expression. It should change the meaning of the entire expression:
> "any script chosen as a result of this expression is forced to run".
> So, you might have: --script '+not intrusive and not discovery'. This
> would mean, "forcibly run all scripts that are not in the intrusive
> and not in the discovery categories". [As an aside with respect to the
> implementation: note that most script filenames are usually matched
> and loaded via the Entry function. The code that runs after this
> comment "-- Now load any scripts listed by name rather than by
> category." loads files and directories that are not found in the
> script database (the script database is a series of calls to the Entry
> function). For example, that fallback code would load scripts
> specified by "my-scripts/foo.nse" or a directory "my-scripts".
>
> With that changed, I think the patch would be much nicer. However...

I agree with your reasoning here, but perhaps I misread you a bit. I think
the '+' should be a prefix to an expression. An expression can be, as
you said:
+not instrusive safe ==> +(not intrusive and safe)
but also:
+http-*    => +(http-*)

Several expressions can be divided up with commas. An expression could
be a single filename, a filename-wildcard, a category or a boolean
expression containing these things. Example with two expressions on the
command-line:

+safe and http-*,+http-title => +(default and http-*), +(http-verb-tamper)
=> "Ignore the return value of the portrule for any script selected
matching (safe and http-*) and any script matching (http-verb-tamper),
unless already loaded"


That would make strange corner cases go away:
(not +http-title) => errror, no + allowed inside expression, + only
allowed at the left side of an expression.

I think this would be a better approach than the current implementation,
since it would still allow the same common syntaxes but would disallow
the weirdness that comes from of mixing + inside expressions.

How does this sound? Is this is the ballpark of what you proposed?
Regards,
/Martin


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