Nmap Development mailing list archives

Re: [NSE][PATCH] OpenSSL bindings for NSE


From: Fyodor <fyodor () insecure org>
Date: Wed, 3 Sep 2008 17:03:05 -0700

On Wed, Sep 03, 2008 at 05:51:00PM -0600, Patrick Donnelly wrote:
On Wed, Sep 3, 2008 at 5:07 PM, Fyodor <fyodor () insecure org> wrote:

Perhaps the message should be printed if verbose is set? I don't see a
cleaner way around this. I believe you meant to return "" in the
action function? The problem is when the script is initially loaded
(executed after compilation). The script could set placeholder
hostrule and action functions which immediately return false and nil
respectively. This seems like an ugly hack to me.

I'm not sure of the best way to implement it, but the desire is to
avoid giving people an error message whenever they run Nmap -A or the
like, just because they don't have an optional library.  Nmap used to
always give a message when run on Windows complaining about lame
random number generation functions, and users hated that.  Similarly,
users who compile Nmap using --without-openssl don't want to be
reminded of that every time they run Nmap.  Version detection does not
print error messages when OpenSSL is missing, it just degrades
gracefully and omits that functionality.  I think NSE should be
similar.

If the user specifies -d or at least 2 -v options, then printing a
short message when OpenSSL is missing is probably fine.  Or if we
expect the scripts to deal with missing OpenSSL themselves, then it is
OK for NSE to print the no-openssl message as a notification that the
script needs to be fixed.

Missing OpenSSL may be a special case.  We probably do want to print
ugly error messages for unanticipated problems so that users will
report them and the issues get fixed.

Also, I think requiring OpenSSL is at least worth considering.  Its
usage has grown significantly within Nmap over the years.  And there
have been other places we've wanted to use it, but were unable to due
to its optional nature.

Cheers,
-F

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


Current thread: