Re: [RFC] Dropping nmap-update from the Windows installer and zipfile

[Fyodor <fyodor () nmap org>]

On Sun, Nov 16, 2014 at 2:01 PM, Daniel Miller <bonsaiviking () gmail com>
wrote:
> The nmap-update tool [1] is a partially-deployed updater for NSE scripts.

It also updates (NSE) libraries, and data files such as the OS/version
detection DBs.

Its use is limited to authorized users (currently limited to just
> developers) and it has not seen any code change since October 2012.

It's true that it's not fully deployed yet, but that's partially because we
wanted to get the updater in everyone's hands (systems) first.  That way
once we broaden it to more widespread use, people are already set up to use
it.  But there are other issues which have delayed wider deployment, such
as figuring out who will do the work to keep it up-to-date.  A nice feature
of nmap-update is that it can handle multiple branches so that people only
get updates which are compatible with their version of Nmap.  But some
housekeeping is required to push new data files to the right branch(es).

Also, it relies on svn, which could be a minor issue if we were to move to
git.  But probably not a major issue, as I imagine we would still keep our
svn server for web content, etc.

As for the lack of code changes since October 2012, that's because we
finished it then.  Now it's blocking on non-code issues such as the
maintenance problem.  We don't want to release it more widely until we're
sure we can support it.

While trying to build it with Visual Studio 2013, I discovered that it will
> not run without recompiling libsvn, because of a version mismatch in
> OpenSSL. The instructions [2] indicate that rebuilding libapr and libsvn
> will not work on a newer Visual Studio than 2008, which reached end of
> mainstream support in April 2013 [3].

Those instructions are more than two years old though and written by us and
not from the projects themselves.  Maybe libapr and libsvn work with newer
compilers now?  I mean they are major actively developed projects.

We should talk about this more, but, unless we think of some other great
alternative for handling updates,  I think we should try and keep
nmap-update and work toward deploying it more widely in 2015.  I think it's
way too hard right now for people to update when we release a new script
for major issues.  Especially if the script requires library changes too.

Admittedly none of my pontificating really helps with the pressing issue
you note about getting the @#$!# libraries compiled.

Cheers,
Fyodor

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