mailing list archives
Re: Updater Investigation
From: David Fifield <david () bamsoftware com>
Date: Tue, 21 Jun 2011 09:47:53 -0700
On Thu, Jun 16, 2011 at 05:32:32PM -0500, Ron wrote:
On Tue, 7 Jun 2011 17:00:17 -0700 Fyodor <fyodor () insecure org> wrote:
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:
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.
I think this is the right approach as well. I was going to suggest the same thing.
One big advantage is that this is compatible with the various Linux
packaging systems that maintain the binaries, and can also be
potentially compatible with Windows/Mac auto-updaters since you aren't
changing the binary files - you're leaving those up to the user to
change on their own. That's a good thing, I think. You're getting the
scripts - which, by design, change quickly - and leaving the core -
which, by design, should be stable and only change periodically.
I don't see how excluding binaries is any more compatible. Linux
packaging owns the non-binary files too. Maybe you mean that we set up a
reserved (initially empty) directory for updated files, that would be
explicitly outside the scope of other package management?
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/