Re: update to nmap-mac-prefixes

[Daniel Miller <bonsaiviking () gmail com>]

On Wed, Jun 17, 2015 at 8:50 AM, Jacek Wielemborek <d33tah () gmail com> wrote:

> W dniu 17.06.2015 o 14:32, Robin Wood pisze:
> > Wasn't there talk at some point about having the ability for nmap to
> > update various aspects of itself through a command line option, might
> > have been scripts? If this is the type of feed that nmap could parse
> > into a datafile that it could use then this would be a good candidate
> > for including.
> >
> > Robin
>
> I just had this thought that this should be relatively easy to implement
> in NSE. What do you think?
As I mentioned in a comment on #152, we have a system called nmap-update
that is not currently maintained. The trouble is that new scripts (and
sometimes new datafiles) are not always backwards-compatible with older
Nmaps. For instance, stdnse.debug is not available in Nmap 6.47 (the latest
stable release). You can get it if you replace stdnse.lua as well as
nse_main.lua, but nse_main.lua has been changed to use lpeg, so you also
need lpeg.lua. Basically you need to grab *everything*, and some stuff
depends on compiled-in NSE libraries. It usually comes around to binary
incompatibility.

So nmap-update has the idea of "channels" where you have a version of the
latest stuff that's backwards compatible with the 6.47 release, or whatever
releases we want to support. But this greatly increases the amount of work
script writers have to do: we have to write backwards-compatible versions
of everything for the users who use nmap-update! This has caused a lot of
pain when we want to push out a new script to detect a hot-button
vulnerability; see for example the lengthy instructions I had to put
together to go with our ssl-heartbleed script:
http://tinyurl.com/nmap-heartbleed

So instead, we just assume that people who want the very latest scripts
will use the SVN repo, and we try to keep the releases coming on a regular
basis. The big delay since the last release has been mostly due to my
learning the ropes of fingerprint integration and the complex processes
surrounding releases, but I hope to have all that smoothed out so that we
can continue pushing releases on a every-6-month-ish timeframe.

Dan

#152: http://issues.nmap.org/152

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/