From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Famulari Subject: Re: Install FAQ: Only build the non-deterministic packages? Date: Sat, 17 Sep 2016 19:35:02 -0400 Message-ID: <20160917233502.GB19908@jasmine> References: <20160916171100.GA1210@lo.psyced.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56504) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blP8i-00044l-SU for guix-devel@gnu.org; Sat, 17 Sep 2016 19:35:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1blP8e-0000cw-LW for guix-devel@gnu.org; Sat, 17 Sep 2016 19:35:19 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:48054) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blP8d-0000Ie-BB for guix-devel@gnu.org; Sat, 17 Sep 2016 19:35:16 -0400 Content-Disposition: inline In-Reply-To: <20160916171100.GA1210@lo.psyced.org> 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" To: carlo von lynX Cc: guix-devel@gnu.org --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 16, 2016 at 07:11:00PM +0200, carlo von lynX wrote: > Hello everyone! Hi, welcome! > Some questions I couldn't resolve from manuals and searches: It's always good to hear this kind of question! > I haven't figured out if there is a way to know which packages > are reproducible. I would like to configure my guix to only > fetch binaries that a sufficient number of people agree on to > be deterministic - and for a start it doesn't even have to be > all digital signatures and stuff: would be enough if the > process is known to be deterministic, so the package definition > carries the checksums for the appropriate binary package with > it. I doubt an attacker would dare to mess with that, at least > not now. >=20 > I just checked git://git.debian.org/git/reproducible/notes.git > but there are only 118 packages saying "deterministic: True". > What happened to the plan of making that database multi-distro? > I also read about the "Reproducible Build Summit" and I am glad > Lunar is still on course. We have `guix challenge` for testing a local build against a binary substitute provider. We also have the '--rounds=3Dn' and '--check' options to any Guix command that builds packages; those options are for repeating local builds and checking if the results are the same. Basically, we need someone to be a reproducibility champion in Guix! We have all the tools to test reproducibility, but somebody needs to implement a system to actually perform the tests automatically, store the results, and make the results available to users. Ideally this person would collaborate with the Reproducible Builds project, since they already have a lot of experience and knowledge about this subject. Help wanted! > I also saw https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D22883 > about trustable "guix pull". Is it still the case that the > update of package definitions is happening over unsecured http? > Concerning git consistency, isn't it enough to run git fsck so > that a mitm intervention would sooner or later be detected? That bug is still open; we still serve `guix pull` over HTTP. We have started signing all commits cryptographically, but my understanding is that we need some method to check these signatures against a keyring, both when receiving new commits on the central Git repo, and on users' machines when they `guix pull`. `guix pull` basically pulls a snapshot, created by cgit, of the HEAD commit of the master branch. This snapshot does not include the .git metadata, and that means no signatures. It is just the Guix source code (hopefully). For now, you can avoid `guix pull` and use Guix directly from a Git repo, where signature checking is possible. I think that `git fsck` is orthogonal to the question of authenticity. Someone could serve a maliciously altered Git clone that still passed `git fsck`. See `man git-verify-commit` for Git's signature checking tool. Personally, I think serving `guix pull` over HTTPS would be a worthwhile improvement while we build a cryptographic commit signature checker. I think that "the perfect is the enemy of the good". More help wanted! > And concluding, do you know if Nix is in any better or worse=20 > condition regarding reproducibility and security of the tool- > chain than Guix? Does nix-pull have the same problem? I do not know but it should not be hard to find out :) > P.S. I'm working with ng0, trying to make a trustworthy system > image for GNUnet/secushare installations. Guix is a top notch > candidate for dissemination. Even if I hate guile and emacs. Guile is obviously unavoidable here, but Emacs is not required at all. I've actually never used Emacs to develop Guix, although I don't dislike Emacs. --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJX3dMiAAoJECZG+jC6yn8IkrYQAIVVnclxhbWy5MXLGOBCIAD1 fuzegnA+1XO62YKPlSK0xossbfWdn7D/RvSrQvy8noStQNo8fbhGMZ85hY5tDrce uCYcaL0Is8AeL9lb2/CeNzCUCv1QX5IVCf43WK7PnzekvEhK8ZOIHGYGmLUCBmYw kumUA1yrMUKf64KqTsOxooigq7k0LXbRAYVNoZk3IhauvOhfwbt0F0NQnaZp6BVu OVNcE2ai9DEDjaovkc1rBxn9swYpc5+/JyoFG1AdL0rlIBHZz6kds6VN2oKos9Hl bojRfvkjOJVl+vShLplv3qqafDqEQfTCQAMNW9y4+QSa9Gd/RP/YaV/O74P4u0Wo KB7KIRerH29UQ6MJsuvQ+zzKCL1FAm6MhJc4KML17AXBQmd0NHtfqpOIk2ST01VD nJPFWgTdE0qPxzBIV8D05Skf6diYUbm9KyV3jFmsV5lIoa2d7bCtXQ3iUndeubEl JphO2PTKNM7+mlWn4gHIhlfYvDzWJ3iVO4W2j1tTa/EKBvZ11s2WvX9AYB6c95W2 FZWKGyk3+IKLpGrlvjWMfFUByXZDpTQp47Eu2y6+WLqgnw+jWDEkM4vJ0ZpM7x5W Y55aLWAa7TDEpynskoA27DUTLmVvI7afJ5K+EBd3Op+Dbg+/5p825NKF+TPQSARg rRxrc74HqjrAn2luAI7z =JuyO -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X--