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/
