Binary security updates

[Colin Percival <colin.percival@xxxxxxxxxxxxxxx>]

  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@xxxxxxxxxxx
with "unsubscribe freebsd-binup" in the body of the message