[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: carlo von lynX
Subject: Re: Install FAQ: Only build the non-deterministic packages?
Date: Fri, 20 Jan 2017 16:55:12 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

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

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


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:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]