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
