Install FAQ: Only build the non-deterministic packages?

Install FAQ: Only build the non-deterministic packages?

[carlo von lynX]

Hello everyone!

Some questions I couldn't resolve from manuals and searches:

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.

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?

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?

Best regards and keep up the good work!

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.


-- 
  E-mail is public! Talk to me in private using encryption:
         http://loupsycedyglgamf.onion/LynX/
          irc://loupsycedyglgamf.onion:67/lynX
         https://psyced.org:34443/LynX/

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

[Leo Famulari]

[-- 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 --]

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

[ng0]

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

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

[Leo Famulari]

On Mon, Sep 19, 2016 at 11:06:40AM +0000, ng0 wrote:
> Leo Famulari <leo@famulari.name> writes:
> > 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.

Since this test would involve building every package at least twice, I
think it wouldn't be possible for most users who would run `make check`.

> > , 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?

Right, I think that testing all the packages for reproducibility is best
done by the continuous integration server, whether Hydra or Cuirass. The
CI server can perform the tests on a variety of build farm machines,
record the results, and present them to users somehow.

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

[carlo von lynX]

Congrats! ng0 just showed me
https://www.gnu.org/software/guix/packages/reproducibility.html

Great file.. and great that I only saw some twenty important
packages that need to be built manually.. most of the stuff
is trustworthy in binary form. EXCELLENT!

Now the perfect thing would be that this list is actually
part of the Guix OS, gpg-signed by several developers and
parsed automatically so that the *default* behaviour of
the guix installation process is to build the non-reproducible
packages while fetching the reproducible ones directly in
binary form.

By the way, "I hate guile" was a joke. I'm just too dumb for it.


-- 
  E-mail is public! Talk to me in private using encryption:
         http://loupsycedyglgamf.onion/LynX/
          irc://loupsycedyglgamf.onion:67/lynX
         https://psyced.org:34443/LynX/

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

[Ludovic Courtès]

Hello!

carlo von lynX <lynX@i.know.you.are.psyced.org> skribis:

> Congrats! ng0 just showed me
> https://www.gnu.org/software/guix/packages/reproducibility.html

Spoiler alert!  :-)

(I haven’t mentioned it on the list yet because it’s not fully baked.)

> Great file.. and great that I only saw some twenty important
> packages that need to be built manually.. most of the stuff
> is trustworthy in binary form. EXCELLENT!
>
> Now the perfect thing would be that this list is actually
> part of the Guix OS, gpg-signed by several developers and
> parsed automatically so that the *default* behaviour of
> the guix installation process is to build the non-reproducible
> packages while fetching the reproducible ones directly in
> binary form.

The problem is that you never know whether a package is reproducible.
At best you can tell that a package is *not* reproducible, but that’s
it.

On the same topic ;-), you’ll probably enjoy these reports:

  https://reproducible-builds.org/events/berlin2016/

> By the way, "I hate guile" was a joke. I'm just too dumb for it.

Not sure what you’re referring to.  However, I can tell that what we’re
trying to do (and what I’m personally interested in) is to show that we
can provide simple interfaces to OS config while not preventing users
from “zooming it” and digging into implementation details.

As such, usability reports are more than welcome, especially from people
who are not professional Lispers!

Ludo’.

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

[carlo von lynX]

On Fri, Jan 13, 2017 at 02:14:24PM +0100, Ludovic Courtès wrote:
> Hello!

Hej Ludó!

> The problem is that you never know whether a package is reproducible.

I see the philosophical debate you had at the summit, but
I think most users would be fine with something pragmatic
that *improves* the probability of software being secure
*compared* to the insecure operating systems of today.

So if 3 guix devs say they were able to reproduce libiberty.so 
for *my* architecture exactly as is distributed by gnunet-fs
or old-fashioned mirror networks, that is a starting point
that is sufficient for *me*.

Reproducible is a static factual goal when you define it
in a focused way on a *specific* version for *one* specific
architecture. If somebody fails to recreate the binaries
that 17 other people were able to create, then that is not
a reason to panic. It simply means there is a bug in the
process. But 17 got the same binary, so *that* binary cannot
be affected by attackers, by men in the middle. That is
enough. That the mechanism doesn't *always* work is
irrelevant for security.

> At best you can tell that a package is *not* reproducible, but that’s
> it.

But that isn't actually important. As soon as two people managed
to compile a package identically, be it because they started
the process in the exact same millisecond, then they created
a binary package that I can trust if I have reason to believe
that these two people would never conspire against me.

Admittedly the term "reproducible" doesn't apply then, but
still that binary package is better than any rpm out there.
So when it comes to facts, the real need on the street is
much easier to achieve as any abstract perfectionism that
may have confused some minds at the summit.

Rok Garbas writes in https://garbas.si/2016/reproducible-builds-summit-in-berlin.html as follows:
| What I realized during the summit is that reproducibility is not something which is true or false, but something that we is true until somebody disproves it. Reproducibility is a goal which we are always working towards, just like security.

But isn't that an overspecification of the problem? Letting
perfectionism distract from the actual goal: having binaries
that a number of other people can confirm to be backdoor-free.
Looks like I should better have been at the summit to help
unconfuse this thinking.

| Getting the involvement outside of the Debian community is high on the list, since everybody realizes that only with common efforts we will be able to achive reproducibility nirvana.

I disagree on this as well. As soon as one distro has the
reproducibility figured out, it has good chances of being
the next big distro of choice. The next debian, the next
Ubuntu. Users don't care for how many contributors are left
behind in the historic distributions. I expect Guix or Nix
to take over similarly as git wiped out cvs and subversion.
A hybrid strategy might survive, as humanity loves backward
compatible kludges.

| Many of us look down on language specific package managers

With all good reasons. Had free software provided an encompassing
package manager that solves the issues, all of these self-service
restaurants shouldn't have materialized. Unfortunately, only when
challenges are *really* hard, like developing a git, a Tor or a
Linux kernel - then the number of alternative projects is limited
and has good reasons to exist - whereas doing your own package
manager is *fun*, or at least it looks like fun at first, so it
will be repeated over and over and the same design mistakes will
be done over and over because the software industry is among the
worst in learning from the past. 

To me the solution is simple. I don't care for a single of those
languages if it won't be willing to make it reproducible. Bad
enough that it takes an older gcc to bootstrap gcc. nodejs folks
may think the world has no chance of turning without them, but
if they don't get their act together, the next most popular OS
of this planet simply will not ship a *single* nodejs app. No
matter how many amazing problems of humanity they managed to
solve in Javascript. If it's not bootstrappable, it is neither
free software, nor open source. It is proprietary software.
These languages should be banned from open source distros as
having to "trust upstream binaries" is a breach of license
and the promise made to the users of FLOSS.

| I got the impression that the sole reason of reproducible builds is that you would be more secure. That implies that everybody cares about security. Which would be great, but in a world with tight deadlines and startups security is usually the first thing that gets crossed out of the list. We need to make a more compelling reason then just security.

As soon as reproducibility is realistic and popular among a
certain percentage of users, professionals and hacktivists,
I can imagine political parties taking the issue into 
parliaments, legislating computer reproducibility as a
precondition for all structurally important systems like
hospitals and traffic lights.

Just look at Windows 10: it has been banned from use in
critical systems in several countries already because of
the obvious remote control facilities inside. Those folks
that legislate such bans need something they can recommend
instead, and Ubuntu certainly doesn't qualify for that.

Computer security is in the news every second day. Parliaments
will be very happy to be able to do something about it. You
guys are key players in this. The YBTI law proposal already
*implies* reproducible operating systems as a precondition.

| reproducibility many times sounds like: all or nothing.

No, as I said having a bunch of packages that need to be
built locally is a bearable compromise.

Even if that bunch of packages is downloaded from the net
*anyway* it means that a lot less packages are susceptible
to corruption - less opportunity for attackers to infiltrate
a system than with Redhat that periodically fetches rpms or
Windows 10 that is remote controllable 24/7.

| What if the main (marketed) reason for the reproducible builds would be to improve developer productivity?

A nice extra, if it can be explained. Certainly not the
main reason.

| But then I realized that BuildInfo effort is actually changing a binary distribution like Debian into a source -> binary like distribution.

Yes, and I expect Guix and Nix to turn out superior
to debian's attempts to rework a several decades long
tradition of an insecure human trust architecture -
let alone the architectural superiority of giving up
the one /usr/lib fits all paradigm. People working on
historic Filesystem Hierarchy Standard compliant
systems are losing time. The future lies in systems
capable of sandboxing each application, Android style.
Standards that are no longer up to speed with the needs
of the time are useless roadblocks for innovation.

| What many do not know about Nix is that Nix is first and foremost a build tool. It only happens that there is a database of packages already described how to be built and a side-effect we get is that Nix can also be a package manager. But initially it is a build tool. Nix can build .deb or .rpm packages or any other format you want.

Having paid respect to Gentoo and BSD Ports for their
pioneering work in the field, I acknowledge that it is
not a path to future, but so I don't yet see debian 
doing itself good by retroactively gentooizising itself.

https://www.gnu.org/software/guix/news/reproducible-build-summit-2nd-edition.html says:
| [...] A refinement of this policy is to install only packages for which k out of n known builders “agree” on what the package contents are.

Of course, since it is enough that a bunch of people that are
unlikely to conspire agree on that. It doesn't matter if others
are honestly or dishonestly unable to recreate the binary.

| We hope we can extend it to support this “k out of n” policy by the next Reproducible Build Summit!

YES YES YES.

I'm busy with a project that has a harder challenge to
solve than reproducibility, but I'm counting on you guys
to handle this issue!

Ludo wrote:
> As such, usability reports are more than welcome, especially from people
> who are not professional Lispers!

Thank you all.  :)


-- 
  E-mail is public! Talk to me in private using encryption:
         http://loupsycedyglgamf.onion/LynX/
          irc://loupsycedyglgamf.onion:67/lynX
         https://psyced.org:34443/LynX/