From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jookia <166291@gmail.com> Subject: Re: Deterministic Library Calls when Building Date: Mon, 21 Mar 2016 04:35:48 +1100 Message-ID: <20160320173548.GA18384@novena-choice-citizen.lan> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54756) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <166291@gmail.com>) id 1ahhJE-0005vI-44 for guix-devel@gnu.org; Sun, 20 Mar 2016 13:38:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <166291@gmail.com>) id 1ahhJA-0002FY-Uz for guix-devel@gnu.org; Sun, 20 Mar 2016 13:38:36 -0400 Received: from mail-lf0-x241.google.com ([2a00:1450:4010:c07::241]:33329) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <166291@gmail.com>) id 1ahhJA-0002FH-N5 for guix-devel@gnu.org; Sun, 20 Mar 2016 13:38:32 -0400 Received: by mail-lf0-x241.google.com with SMTP id w7so462256lfd.0 for ; Sun, 20 Mar 2016 10:38:31 -0700 (PDT) Content-Disposition: inline In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Karl Semich Cc: guix-devel On Sun, Mar 20, 2016 at 12:53:42PM -0400, Karl Semich wrote: > It seems to me it would be the most reliable, future-proof, way, but might > have the downside of making it a step harder for people without the special > environment to reproduce the build. > > I'm pretty new at looking under the hood of linux, but I can imagine these > approaches at least: > - preload system library wrappers around key nondeterministic functions > - replace /dev/*random with fakes (could be named pipes, dummy devices fed > by modules, or just flat files!) > - replace system libraries with fullblown libraries with nondeterministic > calls rewritten (could merge changes upstream, provide a flag) > - create a kernel module which alters the behavior of the running kernel to > be more deterministic > - change the kernel itself to have a "deterministic mode" (could merge > upstream) > > The goal of making packages deterministic would change from modifying the > packages themselves, to modifying the build environment, with the hope of > making a build environment that always creates deterministic builds for > normal software packages. This should be very possible. > > The approach of small library wrappers and/or replacing device files could > be pretty fast to implement, but not as "far thinking" as the other end of > the spectrum, where changes to glibc and linux could be merged upstream. I think this would only really be useful if it could be detected that these sources or nondeterministic functions are being used and flagged for patching upstream.