Nmap Development mailing list archives

Re: Ideas for verbose data file path reporting


From: Fyodor <fyodor () insecure org>
Date: Mon, 4 Jun 2007 21:02:13 -0700

On Mon, Jun 04, 2007 at 04:58:34PM -0600, David Fifield wrote:
I'm working on giving Nmap the ability to tell you where it loaded its
data files from.

Hi David.  I think this will be quite helpful in taming the
overly-complex Nmap data file loading system.  And it is good that you
are paying careful attention to the interface, as I think many people
(particularly developers) underestimate its importance.  Particularly
with a command-line app such as Nmap where you can't easily present
things at different levels of detail as you can in a GUI.

Whatever way you come up with, here are some of my suggestions:

o 99% of the time, all files will be read from the standard directory
  (though different operating systems / packages put that directory in
  different places).  For this case, there should only be one line,
  which basically says that all data files were read from
  /usr/local/share/nmap or wherever.  I would tend to only print this
  in verbose mode.

o For other cases, I like your example "A", though "B" is nie too.  An
  advantage of "A" is that you don't need to create and maintain the
  mapping from filenames to English names.  In this case where files
  are read from multiple directories, I think it would be nice to
  print even when -v wasn't specified.

o Unless it is really easy to add, I wouldn't worry too much about the
  case of changed file names.  You can only do that with the new
  --servicedb and --versiondb options.  If someone is advanced enough
  to use those, they will know from the filename (which they just
  specified) that it is the service file or whatever.

Note that none of these options mentions data files that were not used.
I think it's useful to show which files were opened and which were
not.

I agree.

Cheers,
-F

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


Current thread: