Re: Updater Investigation

[Fyodor <fyodor () insecure org>]

On Thu, Jun 02, 2011 at 01:45:31PM -0700, Colin L. Rice wrote:
> David asked me to investigate more potential updating solutions with
> regards to writing an auto-updater for nmap.

Thanks Colin.  I'm not sure of this, but I'm starting to think we
might want a hybrid approach between
just-updating-platform-independent-files and updating the binaries.
For example, one option is for the updater to do the following:

1) Contact server and ask for the earliest version number (or maybe
   svn revision number) which is suitable for platform-independent
   updates.  The server also gives the current (latest) Nmap version
   number.

2) If host version number or revision date (the one being updated) is
   older than the earliest-allowed provided by server, tell the user that
   their Nmap version is too old for updates and they should visit
   (download page URL) and upgrade to $latest_version.  This isn't
   very hard since we already offer release binaries for 32 and 64 bit
   Linux as well as Windows and Mac.

3) If host version number is at least as new as $earliest_allowed, but
   not as new as $latest_version, consider notifying the user that a
   newer Nmap is available but still do the updates.

4) I suppose it is possible that the host version is $latest_version
   and yet it is still too old for updates.  This might be the case if we
   just made an incompatible change to the NSE engine and we haven't done
   a new Nmap release yet.  This case should be quite rare since we
   should try to avoid incompatible changes, and when we do need them we
   should do a new Nmap release promptly.  In this unusual case, the
   updater could recommend that the user update to the SVN version or
   just wait until a new release.

5) Update the platform-independent files (NSE scripts, libraries, Nmap
   OS database, nmap-services, etc).

6) Whenever we make a change to one of the platform independent files
   which will cause it to not work on older (but still at least as new
   as $earliest_allowed) versions of Nmap, we need to bump up
   $earliest_allowed to the current (post-change) revision date.  We
   could also bump it if it gets to be 6+ months old (or whatever
   period we decide on) to ensure that people update the rest of Nmap
   on a somewhat regular basis.  Besides giving the users a better
   experience, it would mean that we spend less time tracking down
   bugs related to updating to the newest scripts with an ancient
   version of Nmap.

Of course there is the question of what platform-independent files we
should provide.  One option is to include the latest versions in svn,
but that might be too bleeding-edge for some.  Another option is to
maintain a tag/branch in SVN.  It could get bumped forward on an
automated fashion.  Maybe a new file change could be tagged after
there are no further changes to the affected file(s) in 24 hours.  And
we could do it manually if we really badly wanted to push an awesome
new script or change into the update stream.

I'm not 100% convinced this is the right approach, but I wanted to at
least put it into writing as one option.

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