Date: Wed, 25 Dec 2002 13:35:50 +0000 From: Colin Percival <colin.percival@wadham.ox.ac.uk> To: freebsd-binup@freebsd.org, freebsd-stable@freebsd.org Subject: Binary security updates Message-ID: <5.0.2.1.1.20021225125238.037cd840@popserver.sfu.ca>
next in thread | raw e-mail | index | archive | help
I've put together a basic binary updates tool aimed at people who want to track a security branch without keeping a source tree and recompiling. I have tested this code to the best of my ability -- but since I only have one FreeBSD box (and it's on the other side of the world), that ability is rather limited. The modus operandi of this tool is simple: Build a -RELEASE world, build world(s) along the security branch, and compare. Unfortunately the details are a bit more complicated: Before comparing we have to strip out various time/date/user/host stamps -- stamps which we locate by building the same world twice. An RSA key is generated and used to sign the updates for security purposes. Once signed, however, the updates can be distributed via insecure means (eg, HTTP). At the client side, updates are fetched (and verified) into a staging directory; they are then installed on command (preferably in single-user mode, of course) and a rollback directory is created. In order for files to be updated, their original MD5 hashes must be correct, so any local modifications to the world will result in files not being updated. A few more incidental notes, in no specific order: 1. The practice of bumping newvers.sh for security updates leads to world-only updates causing the kernel to change. As a workaround, my code replaces the kernel stamp with a generic -SECURITY stamp. 2. /usr/lib/libobjc.a (and _p.a) is wierd; it is the only file in the world which builds completely differently every time. As a result, it gets ignored -- any security updates here will not be propagated. 3. A few other files (.../perllocal.pod, ...doc/psd/*, ...doc/usd/*, ...phantasia/void) are obviously not security-related, but have some messy variability; I'm ignoring those files as well. 4. I just realized that I'm snapping hard links if any such files need updating. Oops. 5. Anything else which doesn't update properly if it has another file mv'ed onto it won't be updated properly. I'm not sure if this applies to anything except /boot stuff. 6. In order to locate the time and date stamps, I play games with the time; the server code won't work properly if you have anything like ntp running. 7. The license is unusual. GPL fanatics will probably not be very happy. 8. This code should not be used to update anything other than a binary install of -RELEASE: If you use it to update a world you have built yourself, some files will not be updated (due to differing MD5 hashes). Thanks to: Chad David and Terry Lambert for helping me understand the build process; Nick Geyer and netwave.com for giving me some temporary webspace while I work out where I'm going to put this permanently. Now, for those of you who have read this far: The server code is at http://cperciva.netwave.com/freebsd-update-server.tgz with MD5 hash a9bbf3f514314b2e63ce54cc85246bd8 The client code is at http://cperciva.netwave.com/freebsd-update-client.tgz with MD5 hash 35da1fb837edf4fb86979d728c24d719 The client code includes a configuration file which will fetch updates (from 4.7-RELEASE to RELENG_4_7) which I have published -- I leave it up to you to decide if you want to trust me. Note that the above URLs are temporary; at some point I'll move these to a more permanent home. For that reason, I'd suggest not linking to them. Merry Christmas, Colin Percival To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.0.2.1.1.20021225125238.037cd840>