Nmap Development mailing list archives
Re: Updater Proposal
From: Marek Lukaszuk <m.lukaszuk () gmail com>
Date: Thu, 19 May 2011 11:01:32 +0200
On Wed, May 18, 2011 at 22:08, olli hauer <ohauer () gmx de> wrote:
On 2011-05-17 05:58, David Fifield wrote:On Sun, May 15, 2011 at 08:28:02PM -0400, Colin L. Rice wrote:Hello Everyone, I'm Colin on of the new GSOC students. As part of my task I want to implement a auto-updater for nmap. However before I write it I need to figure out how to implement it and how limited it is. So I have been researching this and would like to present a couple of options for discussion. We first have two choices 1) Write an updater which only touches the platform independant files such as the lua and NSE libraries as well as nmap-service-probes, nmap-services, nmap-os-db. This could be used not only to update old versions of nmap but also to update users to the latest scripts, services, and os probes without updating the entire nmap library and allowing new changes to be distributed quickly. 2) Write an updater which updates everything. This simplifies worrying about whether the scripts will work with the current version but you do have to make sure you are getting the correct binary.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. 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.Once you have made those choices you have to decide how you wish to insure download integrity. There are again a couple of options. 1) Use a framework such as TUF which is set up to basically handle hostile attack gracefully and can deal with everything from compromised keys, hostile mirrors, and man in the middle attacks. https://www.updateframework.com/browser/specs/tuf-spec.txtI'm impressed with the thought that has gone into TUF. I learned about some packaging attacks I wouldn't have thought of right away, like feeding a client stale metadata to make them think they're up to date when they're not.2) Use a simpler system which is wrapped around bsdiff or courgette where all that is maintained is that the patches are signed by the correct source, that the patches are newer than the current version, and that there has been no corruption during transmission.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. David FifieldIf you are looking at bsdiff from Colin Percival, then maybe also look into the concept of the FreeBSD patch system. I think with some work you can rewrite the scripts to update the binaries and nse scripts. http://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-update-server/article.html http://www.freebsd.org/cgi/cvsweb.cgi/projects/freebsd-update-server/ I suspect the *BSD users prefer the update by source system. To limit traffic it may be a good idea to provide a .tgz file without the mswin32 sources which are not really usefull on this platforms
All the discussion so far, as I can see (sorry if I missed anything) is about how to make sure that the whole update process is secure, but I didn't see any discussion on the performance on the update servers that this could have. Currently there is a lot of nmap users out there and when they all start to run the version of nmap that will support autoupdates/upgrades the amount of the traffic generated could be significant. Maybe a thought of a different transport mechanism to spread the load of the updates - torrent for example or something similar. Just an idea to think about. Marek _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Updater Proposal Colin L. Rice (May 15)
- Re: Updater Proposal alexandru (May 16)
- Re: Updater Proposal David Fifield (May 16)
- Re: Updater Proposal Fyodor (May 18)
- Re: Updater Proposal Colin L. Rice (May 18)
- Re: Updater Proposal olli hauer (May 18)
- Re: Updater Proposal Marek Lukaszuk (May 19)
- Re: Updater Proposal David Fifield (May 19)
- Re: Updater Proposal Daniel Roethlisberger (May 19)
- Re: Updater Proposal Shinnok (May 19)
- Re: Updater Proposal Fyodor (May 18)
- <Possible follow-ups>
- Re: Updater Proposal ricec2 (May 19)
- Re: Updater Proposal Hani Benhabiles (May 25)
- Re: Updater Proposal David Fifield (May 26)
- Re: Updater Proposal Hani Benhabiles (May 25)