mailing list archives
Re: Updater Investigation
From: Fyodor <fyodor () insecure org>
Date: Tue, 7 Jun 2011 17:00:17 -0700
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
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.
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/