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

[ng0 <ng0@we.make.ritual.n0.is>]

Leo Famulari <leo@famulari.name> writes:

> [ Unknown signature status ]
> 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

Do we have comparable tests available in th test suite of guix?
If not, I'll open a bug on this so that someone with competence in the
test suite can put it on their todo list.

> , store the results, and make the results available to users.

Could Cuiriass - or what our soon-to-be-replacement of hydra is called
again - do this? Have one testing checkout where all the packages will
be run again the test(s) we created before and then process the build
logs?

> 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".

What's left to solve to serve guix pull over https?

> 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 :)

nix-channel --update (seems) to call https. If you look at core nix (not
NixOS), they are working on something similar like I am for Guix and
GNUnet, there's slow work going on in moving everything (including all
the package sources) to some distributed system (forgot which
one). However looking at some open issues on their bugtracker it seems
that channels are not signed, released are not cryptographically signed,
https is only working (statement from 2014, open bug) for hydra nixos
cache, the ones which are using amazon will not work with https because
the certificates are signed by amazon.

>> 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.

-- 
              ng0