Re: Script force

[Fyodor <fyodor () insecure org>]

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
> default"

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
> already loaded.

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.

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