Re: Updater Proposal

[Fyodor <fyodor () insecure org>]

On Mon, May 16, 2011 at 08:58:44PM -0700, David Fifield wrote:
> My gut impression is that updating everything will be easier, because
> then we don't have to worry about what to do with mismatched binaries
> and scripts. 

That is my gut instinct too.  Plus, updating only the
platform-independent files misses out on a whole lot of Nmap goodness.

> But it doesn't support one use case that people have asked
> for, which is to get some updated scripts in between major Nmap
> releases.

I see that not just as one use case, but as the main point.  We
already distribute binaries for all three key platforms which provide
easy upgrades between releases.  At most, you only have to download
and run a quick self-installer.  But what about when we add the next
Conficker detection script or the next afp-path-vuln?  Previously we
had to go through all the trouble of making a new Nmap release and (in
the Conficker case) suffer a bit of downtime and a bit of
excess-bandwidth-charges from all the traffic.

But a system which starts out only working between official releases
might be OK as long as there is a path to allowing at least daily
updates.  This might mean us setting up four build servers (one each
for Windows, Mac OS X, 32-bit Linux, and 64-bit Linux) so that daily
builds can be handled automatically.

Of course, we can't have people downloading new complete installers
daily.  If the only changes in a given day are to NSE scripts or
libraries, it should ideally only download those scripts/libs (or even
better: a compressed set of just the changes in just those scripts or
libraries).

Maybe some sort of combination system could work.  Like a system which
only handled the platform-independent files on a daily basis.  But to
avoid us having to always maintain backward compatability, the updater
first checks a file we maintain on the update server which gives the
minimum Nmap version/date required to download the latest files.  If
the Nmap trying to update isn't new enough, it either upgrades Nmap
(via TUF or whatever), or just tells the user that they'll have to go
to nmap.org and upgrade in order to keep receiving new scripts.

> You have the right idea here. At the very least, we need to achieve
> parity with what conscientious downloaders can already do by verifying
> PHP signatures on releases. If an updater does verification
> automatically, then perhaps we can even get a majority of users
> verifying their updates.

It might be hard to achieve true parity, since the current system
requires me to sign the files on one of my systems at home and then
upload the signatures.  I can't do that on a daily basis.  But yes, it
definitely needs to be secure.

I hope my mail doesn't sound like I know the answer to these problems
:).  I'm just sending some feedback and ideas, but I'm still kind of
stumped about the best way to implement this.  I'm looking forward to
Colin's research and ideas!

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