On Mon, Apr 30, 2007 at 04:21:34PM +0200, Maurice Janssen wrote: > On Sunday, April 29, 2007 at 02:35:06 +0100, mal content wrote: > >I'm extremely interested in binary updates as I don't yet have the resources > >to put together a build server and compiling updates in qemu is very > >painful. > > > >Until these binaries are trusted by the OpenBSD project though (which is > >to say, possibly never), I can't really afford the risk of putting them on > >live machines. Sorry. > > > >I expect you'll receive other replies along the same lines. > > Yep, I also received some email off the list with the same reason. > Which I can fully understand, of course. > > Perhaps this will evolve into something that's an official part of > OpenBSD. I'm not sure how, but we'll see how it goes from here.
This is just an idea, and might well be completely retarded/wrong, but: Unless I am mistaken, the reason that compiling the same binary twice yields different results is that gcc adds some randomness (barring special circumstance like including date, time, host and version in the kernel, and so on). If one were to extend gcc to accept random data from a file as well as the usual sources (/dev/arandom and such, I suppose), would this not make sure that, given the original random data, one always gets the same binaries? And, by extension, the same tar.gz? (Although I'm beginning to think that the latter would most likely not work without some additional trickery - *something* is bound to have the compilation time or host in there. For the same reason, it wouldn't work with kernels, but compiling a kernel is much faster than compiling everything, and hacking the kernel build script to include whatever one wants can't be that difficult, anyway.) If this idea is correct, and I am correct in thinking that I could hack this into gcc, the project would only have to provide the random data (I don't think the exact data matters, as long as everyone uses the same and it's actually somewhat random, but a known-good source can't hurt). In the absence of a nicer way to validate releases, which will doubtlessly be provided soon, simply posting an appropriate checksum (SHA1 or SHA256) to misc@ would suffice. Do note the disclaimer at the top, though... Joachim -- TFMotD: afterboot (8) - things to check after the first complete boot