Re: Thoughts on script documentation

[Fyodor <fyodor () insecure org>]

On Wed, Jan 05, 2011 at 09:21:28AM +0100, Jan-Oliver Wagner wrote:
> On Mittwoch, 5. Januar 2011, Fyodor wrote:
> > Because of these limitations in the "svn up; make" update system, we
> > may introduce a formal feed for Nmap script and data files at some
> > point.  But deciding on the best way to do this will take a lot of
> > thought.  And we'll have to either add features for recognizing
> > incompatibilities (e.g. scripts which use features which aren't
> > available in the user's version of Nmap) or we'll have to include new
> > executables in the update feed too.
>
> The latter is the path to the dark side of the force ... ;-)

I'm not sure about that.  I think most Nmap users on Linux get their
Nmap (and other software) updates through their distribution's
repository system, which means updating the binaries as well as
scripts.  Firefox might be a better example, since they have a
multi-platform update system which can replace the engine as well as
the architecture-independent files.  It might be worth examining more
how that works.  Most Adobe software can be updated that way as well,
and that is how Microsoft Windows Update works too.  Windows Update is
Windows-only, but you get different binaries based on the version of
Windows you are using.  Apple's iPhone App Store and new Mac App Store
include binary update features.

A big disadvantage of including platform-specific updates in an Nmap
update system is that we'd need separate architecture-dependent
channels and of course we'd have to build the binaries for each
channel.  On the other hand, we already have such build systems
available because we need them to build the new release binaries.  The
advantages of such a system are that people would get the newest
version of Nmap as well as its scripts, and we also wouldn't have to
develop a dependency system to track the Nmap engine version required
for each NSE script.  We would just have to make sure to include new
binaries in the update stream whenever we make a change which is
required for the newest scripts/libs.

I'm not saying that a binary update mechanism is certainly the way to
go, but we should keep it on the table.

Of course the update system would have to utilize cryptographic
signatures to prevent rogue updates (e.g. from MITM attacks).  But
that is true even if we only update platform-independent code.  A
rogue NSE script or library is roughly as dangerous as a rogue Nmap
executable.

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