From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: The fixed-point project Date: Thu, 19 Sep 2013 23:24:52 +0200 Message-ID: <87li2sy063.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42330) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMlnZ-0008NX-Ea for guix-devel@gnu.org; Thu, 19 Sep 2013 17:30:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VMlnV-0006cm-2y for guix-devel@gnu.org; Thu, 19 Sep 2013 17:30:05 -0400 Received: from hera.aquilenet.fr ([141.255.128.1]:42838) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMlnU-0006ce-PL for guix-devel@gnu.org; Thu, 19 Sep 2013 17:30:01 -0400 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id 50A0DD03 for ; Thu, 19 Sep 2013 23:24:58 +0200 (CEST) Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHUkEioXfPcn for ; Thu, 19 Sep 2013 23:24:58 +0200 (CEST) Received: from pluto (reverse-83.fdn.fr [80.67.176.83]) by hera.aquilenet.fr (Postfix) with ESMTPSA id E32F6B99 for ; Thu, 19 Sep 2013 23:24:57 +0200 (CEST) List-Id: 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: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello! Our wonderful manual, under =E2=80=9CBuilding the Bootstrap Binaries=E2=80= =9D [0], questions when we reach fixed point. I rebuilt the bootstrap binaries in an attempt to answer that question. Basically, after two runs I got the bit-for-bit identical tarball for Binutils, but the other 4 tarballs differed. The differences were a 4-byte CRC related to .gnu_debuglink (for files that had that), a timestamp in Guile, and non-determinism in the way Guile generates identifiers at macro-expansion time. I=E2=80=99ve fixed some of that, and the rest should be easy to fix. Then = we quickly reach fixed point. Neat, no? :-) Actually it=E2=80=99s Christian Grothoff who prompted me to look at this du= ring the GHM, for several good reasons. First, when we achieve fixed-point, users can just run =E2=80=98guix build bootstrap-tarballs=E2=80=99 at home and notice that they get tarballs that = are bit-for-bit identical to those referred to in bootstrap.scm. That tells them that the recipe they have is really the one that was used to build those tarballs (whereas currently they have to trust me.) However, in theory, that doesn=E2=80=99t save us from trusting-trust attacks=C2=A0[1]: the bootstrap GCC could contain a trap, such that the trap is always preserved across recompilations of GCC, even if it=E2=80=99s abse= nt From=20the GCC source being compiled. David A. Wheeler=E2=80=99s thesis [2] addresses this topic. Roughly, it sh= ows that a compiler can be tested for traps by relying on a =E2=80=9Ctrusted=E2= =80=9D compiler [3]. For Guix, though, another variable is time: if the current bootstrap binary is taken for =E2=80=9Ctrusted=E2=80=9D, then it may be enough to bui= ld the whole chain of trust, for the rest of time. That is: we may be able to show that we obtain the same bootstrap binaries regardless of whether we use the current bootstrap binaries (taken for trusted), or those just built (under test). Even better, Guix can cross-compile, so we could inject cross-compiled bootstrap binaries as the input, and use them as the starting point to rebuild bootstrap binaries. These should be bit-for-bit identical to those obtained with other bootstrap binaries. A next step would be generalized bit-for-bit reproducibility [4]. That=E2=80=99s going to be more work, because each package may have non-determinism issues of its own that need to be fixed. This is also something the Nix people have been looking at [5]. Anyway, that opens up a whole lot of perspectives that seem very useful now that the (arguably unsurprising) state surveillance has been exposed. Thoughts? Comments? Thanks again to Christian for insisting ;-) and for the enlightening discussions we=E2=80=99ve had, and to Mark H. Weaver for pushing some more. Ludo=E2=80=99. [0] http://www.gnu.org/software/guix/manual/guix.html#Bootstrapping [1] http://cm.bell-labs.com/who/ken/trust.html [2] http://www.dwheeler.com/trusting-trust/ [3] https://www.schneier.com/blog/archives/2006/01/countering_trus.html [4] https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar= -and-global-compromise [5] https://nixos.org/wiki/Long-term_open_issues:build_determinism --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iEYEARECAAYFAlI7a6kACgkQd92V4upS7PQMmwCdFJSch8iqIY4v17fHgzl3DyCx vvgAoIEc6Y6jswR47EalL+m6R1RqZLJ9 =2Aa5 -----END PGP SIGNATURE----- --=-=-=--