Nmap Development mailing list archives
Re: Updater Proposal
From: olli hauer <ohauer () gmx de>
Date: Wed, 18 May 2011 22:08:51 +0200
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 Fifield
If 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 olli _______________________________________________ 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)