mailing list archives
Re: Script force
From: Fyodor <fyodor () insecure org>
Date: Wed, 30 Nov 2011 16:11:27 -0800
On Wed, Nov 30, 2011 at 02:25:44PM +0100, Martin Holst Swende wrote:
On 11/30/2011 12:11 AM, David Fifield wrote:
I didn't know the syntax above was even possible, I thought boolean
operators only applied to categories (or wildcards), not filenames: safe
and (discovery or default).
Yeah, the're operators are pretty powerful.
Another interesting usecase : "not +default" ==>? hopefully same as "not
That sounds right to me too.
Also, even supposing that the "or" would retain the force value, what
should happen in cases like this?
http-title or +http-*
Ideally, it should load http-title normally, then load the rest of the
http-*-scripts with force flag set, but it should not load http-title
again, since that is
That would probably be fine. Also consider what should happen in the
reverse case "+http-* or http-title". But I don't think we have to
put a lot of work into making these strange cases work a certain way.
I think the key is that they either work in a reasonably
predictable/justifiable way or give an error message.
I also tried
+(default or vuln)
I didn't really expect it to work. This was the output:
NSE: failed to initialize the script engine:
[string "rule"]:1: attempt to call a boolean value
The syntax +(default or vuln) would be nice to support, but I don't know
how much work it would be. I'll look into it.
Personally, I wouldnt spend much time/code implementing this. After
all, the user can easily enough just do "+default or +vuln" and that
is even shorter in this case because you don't need parens. But it
would be great if we gave a better error message. It would be nice if
it at least said that the --script argument was invalid and maybe
print the argument used.
Well, just for completeness, it would be nice to support as much as
possible that makes sense.
Yeah, I can see some boolean cases that are legitimately useful. So
if they can be easily implemented and don't cause too many bad corner
cases, I think it would be a plus. But if banning '+' and booleans is
much easier, that's fine too.
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/