From owner-freebsd-hackers Sat Aug 10 6:13:49 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB18F37B400 for ; Sat, 10 Aug 2002 06:13:46 -0700 (PDT) Received: from pd2mo3so.prod.shaw.ca (h24-71-223-10.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 348DE43E5E for ; Sat, 10 Aug 2002 06:13:46 -0700 (PDT) (envelope-from Colin_Percival@sfu.ca) Received: from pd5mr2so.prod.shaw.ca (pd5mr2so-qfe3.prod.shaw.ca [10.0.141.233]) by l-daemon (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 12 2002)) with ESMTP id <0H0M00F0BQ2XEJ@l-daemon> for freebsd-hackers@freebsd.org; Sat, 10 Aug 2002 07:13:45 -0600 (MDT) Received: from pn2ml9so.prod.shaw.ca (pn2ml9so-qfe0.prod.shaw.ca [10.0.121.7]) by l-daemon (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 12 2002)) with ESMTP id <0H0M00D10Q2XK2@l-daemon> for freebsd-hackers@freebsd.org; Sat, 10 Aug 2002 07:13:45 -0600 (MDT) Received: from piii600.sfu.ca (h24-79-84-133.vc.shawcable.net [24.79.84.133]) by l-daemon (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 12 2002)) with ESMTP id <0H0M00H07Q2WL2@l-daemon> for freebsd-hackers@freebsd.org; Sat, 10 Aug 2002 07:13:45 -0600 (MDT) Date: Sat, 10 Aug 2002 06:13:11 -0700 From: Colin Percival Subject: Re: release variability In-reply-to: <3D52209F.CC0B6DAA@mindspring.com> X-Sender: cperciva@popserver.sfu.ca To: Terry Lambert , Colin Percival Cc: freebsd-hackers@freebsd.org Message-id: <5.0.2.1.1.20020810024458.02035e48@popserver.sfu.ca> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <5.0.2.1.1.20020808000218.01fcd120@popserver.sfu.ca> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 00:41 08/08/2002 -0700, Terry Lambert wrote: >Colin Percival wrote: > > If two people `make release` on different machines, how much difference > > will there be between the results? Obviously the kernel will be different > > because it contains the user and host names from its build; should > > everything else be the same? > >Assuming identical source trees, and that the build takes place >on systems installed with the same software, the only things that >should be different are user, host, and time stamps. The kernel >is one place that's stamped; the boot code is another. And, unfortunately, there's a hell of a lot more. I've grabbed the 4.6-RELEASE source tree and ran a make world - chroot - make world twice, and here's what I found: /kernel, /boot/loader, and /boot/pxeboot all contain user, host, time, and date stamps, as expected. All .a files (126 in /usr/lib, one in /usr/libdata/perl/5.00503/mach/auto/DynaLoader) contain some sort of indices of .o files, including seconds-since-epoch stamps User, host, time, and date stamps are found in /etc/mail/freebsd.cf /usr/sbin/named /usr/libexec/named-xfer Time and date stamps are found in: /usr/bin/suidperl /usr/bin/ntpq /usr/sbin/ntp(d|date|dc|timeset|trace) /usr/sbin/isdn(d|debug|monitor|phone|telctl) /usr/libdata/perl/5.00503/mach/perllocal.pod Date stamps are found in: /usr/sbin/ppp /var/db/port.mkversion /usr/share/doc/usd/(07.mail|13.viref|18.msdiffs|19.memacros|20.meref)/paper.ascii.gz (once you ungzip them) /usr/share/perl/man/man3/(Config|DynaLoader).3.gz (once you ungzip them) Files which are always the same size, but seem to have completely different contents: /usr/share/games/fortune/*.dat /var/games/phantasia/void This raises two questions: 1. Is there any way I can set up my system to consistently build the same world? The user and host are of course easy to fix; I'd consider running a daemon to reset my clock every second in order to keep the time stamps consistent, except that I don't think it would work, and I worry that it might break `make` anyway. 2. Is this really a desireable state of affairs at all? As it is, it is practically impossible for someone to `make release` on their own and compare their version to the official version to ensure that the build was correct. Reproducibility and verifiability are rather important matters when it comes to security. Colin Percival To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message