Re: Install FAQ: Only build the non-deterministic packages?

[Leo Famulari <leo@famulari.name>]

[-- Attachment #1: Type: text/plain, Size: 3797 bytes --]

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.
> 
> 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=n' 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=22883
> 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 
> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]