Date: Mon, 20 Jul 2015 14:25:31 +0800 From: Julian Elischer <julian@freebsd.org> To: freebsd-hackers@freebsd.org Subject: Re: reproducible builds of FreeBSD in a chroot on Linux Message-ID: <55AC945B.20305@freebsd.org> In-Reply-To: <1437322490.1334.381.camel@freebsd.org> References: <201505071122.36037.holger@layer-acht.org> <554B509B.8020608@fuckner.net> <201506162350.11646.holger@layer-acht.org> <CAPyFy2DExDdGf8hN2DNJCSgnP2dj_cLm_TXf1Y8tNJ%2BygvqRzg@mail.gmail.com> <20150718180928.GE8523@funkthat.com> <1437322490.1334.381.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/20/15 12:14 AM, Ian Lepore wrote: > On Sat, 2015-07-18 at 11:09 -0700, John-Mark Gurney wrote: >> Ed Maste wrote this message on Wed, Jun 17, 2015 at 16:48 -0400: >>> These are used only as user-facing strings for the kern.version sysctl >>> and reported by uname. An example kern.version string: >>> FreeBSD 10.1-STABLE #28 r280427+86df2de(stable-10): Thu Mar 26 16:07:47 EDT 2015 >>> emaste@feynman:/tank/emaste/obj/tank/emaste/src/git-stable-10/sys/GENERIC >>> >>> >From a technical perspective they're trivially eliminated. There may >>> be some 3rd party ports expect the precise format, but probably not >>> very many (and they should be fixed, anyhow). There's a much larger >>> social issue in convincing the FreeBSD developer community to accept >>> their removal, though :-) >> I don't know about others, but IMO, the only useful information there >> is the path it was built from... The machine isn't too useful and even >> less useful is probably the build user... Maybe on larger installs, >> the user/machine makes a difference, but that could be a config option >> to include those... >> >> So my vote is to eliminate user/machine and just leave the path... And >> we could just use user@machine to keep the format compatible, but >> constant... >> > If you have a procedure that does builds in a chroot, the path holds no > useful information at all, and the user@machine (plus date) is the real > information. Obviously to get a single binary file that is bit-for-bit > identical to another build, some of this identifying information will > have to be scraped off[*], but please leave the choice of what to > include or remove up to the user/admin. I'm hoping the original OP has looked at what Colin Percival does for the freebsdupdate stuff. That creates annotation of all the unreproducible parts (e.g. date stamps) and makes sure they are not confused with real changes. > -- Ian > > [*] Or we have to be more selective about what "bit for bit identical" > means, such as placing variable information that can't be lived without > into its own section in the file and have a compare/verify tool that > knows how to ignore that section. > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55AC945B.20305>