mailing list archives
Re: Script force
From: Martin Holst Swende <martin () swende se>
Date: Wed, 07 Dec 2011 09:18:43 +0100
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
+not instrusive safe ==> +(not intrusive and safe)
+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
+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?
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/