@jschwart reprodukcje builds are interesting from a technical view, but a free system with or without them is still a free system. https://www.fsf.org/campaigns/priority-projects/ has a good run down of current challenges that we need to solve.
reproducible builds (along with a bootstrap-from-scratch path) are requirements to ensure that there aren't nonfree artifacts leaking into our binaries, methinks
@jschwart If it is free software, yes. Reproducible or not doesn’t matter if I can look at the code .. and run it myself and not have someone else run it for me.
I guess you're right, in a way. if you have a fully-free bootstrap path, you don't need reproducible builds to tell whether your binaries have had blobs introduced in them that aren't present in sources. it's a tool to check for blobs, much like the script we maintain to scan for blobs in linux. so I wouldn't say it's unrelated with freedom, but it's a investigation tool, rather than a requirement
@amszmidt hmm, maybe the other way around? When the Dutch COVID applications came, they used some sort of notary process to assure the binaries were generated from a particular source revision. As citizens are faced with programs by their governments, it is important to have legal requirements for any distributed binaries to have matching source code along with bit-for-bit reproducability. Maybe you trust free software like GNU, but will you trust it just the same from your government? :)
@jschwart i don’t think more trust is needed, free software has a significantly higher trust than anything propeitery… (this is not to say that RB is not good.. it is like GC in languages…)
@amszmidt yeah you are right. I do think they can help a lot to create extra trust towards free software, at a level that non-free software can never have. But it indeed does not relate directly to software freedom. Regarding the challenges, I think reproducible builds would be a strong selling point for adoption by governments.
IMHO the GNU FSDG and typical copyleft licenses require build scripts because building certain programs involves elaborate procedures, and depriving users of Makefiles, configuration programs and whatnot would be a relatively trivial (and thus prone to abuse) way to keep users from being able to enjoy the freedoms to adapt and to improve the program. licenses and guidelines that strive to defend users' freedoms thus must stand in the way of such trivial attacks, just as they they do of more elaborate attacks.
@janneke@vagrantc You said that they are essential. That means .. software freedom CANNOT exist without RB. Clearly that is absolute nonsense. And yeah, I can actually look at the files.
@amszmidt@vagrantc Humans have survived perfectly well for longer periods than 40y without software freedom.
Ignorance is a very powerful mechanism that can hardly be underestimated.
Unless you are running GNU Guix, you are most likely running pretty large pre-built binaries that you have downloaded.
If you cannot reproduce the same binary from the source code, how can you be sure you are running the source code you inspected? You can't, without Reprocuducible builds, software freedom is just another nice and cozy fairy tale.
@janneke@vagrantc if they are essential, then I wonder how we have survived for forty years and will survive for another forty without them.. no.. they are not essential. They are irrelevant.
Reproducible Builds are valuable if you're taking someone else's binaries, but not essential for one to achieve software freedom. having freely-bootstrapped tools and using them to build free source code gets you free binaries, even without any reproducible builds
The crux of my talk was that Reproducible Builds, Bootstrappable builds and Free Software may each be independently useful, but much stronger if you have all of them.
Reproducible Builds demonstrates a strong connection between the source code and the binaries to be run, modified or shared.
Bootstrappable Builds strengthens confidence in the toolchain.
Free Software makes it possible to verify the other two by independent third parties.
Incomplete source code that compiles and runs, but behaves differently in subtle ways depending on any number of non-deterministic factors... how does someone verify that? Or complete source code with compomised toolchain?
The promises of Free Software are a little empty if you cannot verify the results.
Weather it should be part of a Free Software definition, I don't know... that gets complicated!
@amszmidt@ekaitz_zarraga@loke@vagrantc Although I'm not quite ready yet to suggest we need a fifth freedom, "freedom 4": the freedom to bootstrap the program (and re-create it bit-for-bit?)...
...if I don't distribute a binary---that otherwise may or may not not fully or partly match the sources---together with my software, how would you ever exercise your "freedom 0" to "run it as you wish"?
How does un-runnable software (or a binary that you could run if you're feeling brave but cannot not re-create) ever give you software freedom?
@ekaitz_zarraga@loke@janneke@vagrantc None of it has a bearing if you have the ability to run, study, modify, or distribute a program. Those are the four freedoms.
@loke@amszmidt@janneke@vagrantc Sure! But reproducible builds and bootstrappability take part in the same process. If the result of a compiler is not reproducible you can't make sure one thing was compiled as you were told it was, so you cannot make sure it doesn't have extra "goodies" inside. Bootstrappability takes the same thing and stretches it to the very root of the problem.
@amszmidt@janneke@vagrantc When Janneke says they are essential is because without Bootstrappability you can't actually know that your binary comes from the source you were given so it might not be free software what you are running. This premise is just factually true. Another thing, that is opinable, is if you care about that or not.
@janneke@vagrantc Your base claim was that RB are essential for software freedom, yet .. we have the software freedoms that do not mention anything like that. We have a plethora of free software licenses that do not require RB.
Just like we have build scripts requirements in the GNU GPL, that too is not a _essential_ requirement for software freedom.
@janneke@vagrantc Your changing the subject. Software freedom and the GNU GPL are quite different in goals, the GNU GPLs goal is to see that the user and developer can achieve the same thing (DRM in GPLv3 e.g.,). Software freedom is seeing that you can control what your computer can do. The reason why the GNU GPL requires "build scripts" is to make sure that you and the person you got the source from have the ability to do the same thing. Software freedom does not have such a requirement.
the point of software freedom is not enabling verification, but control of one's own computing. I'm not saying verification and thus RB is undesirable or not valuable, just that we can get software freedom without them. as long as you can modify and build the program against your own bootstrapped build of the library, it is not relevant for your software freedom whether a third-party binary depended on another undesirable version of the library, or whether that third-party build is reproducible. one may argue that, at least in some such cases, the resulting third-party binary is not freedom-respecting, because of the blobs it carries, but if you have software freedom, you can rebuild it and avoid relying on the blobs. in extreme cases, getting a freedom-respecting binary to run in freedom may require implementing a free compatible library.
@lxo Right; if the program cannot be (easily) built, script or build-system-wise, it cannot be copylefted.
Without a new "freedom 4" (the freedom to build/bootstrap a program and re-create it bit-for-bit using free software) it would still be OK to require build dependencies that themselves cannot be built (or only by injecting pre-built binaries that cannot be verified to have been built exclusively with free software) and copyleft the program.
"impossible" is far too strong. that goal can be achieved with local bootstrapped builds alone. reproducible builds on top of that enable builds towards this goal to be shared and reused in a verifiable way, borrowing others' computing power without losing sacrificing much trust. (you sacrifice some trust unless you spend the computing power to reproduce the builds)
@lukeshu@amszmidt@lxo@vagrantc IOW, without bootstrappable builds and reproducible builds, it's impossible to prove the absense of a "incomplete source code bug".
Without bootstrappable builds/reproducible builds, having "some source code" available cannot give any guarantee of software freedom when using this program.
@amszmidt@lxo@janneke@vagrantc I'm not going to argue that RB is a "requirement" (lxo's word) or "essential" (janneke's word) for software freedom, but I am going to argue for "helpful", which is contrary to it being "irrelevant" (ams's word).
As a (former?/AWOL) distro packager for a totally free distro (Parabola), and someone working on RYF hardware:
RB helps/would-help us verify that we are shipping the complete corresponding source code.
As ams says, "incomplete source code" is a "bug". But it's a bug that affects software freedom. GC helps prevent memory bugs; RB helps prevent software freedom bugs.
that, too, comes across as an exaggeration to me. although there is potential for compilers to implement "reflections on trusting trust", those are the exception rather than the rule. in nearly every case, using any compiler to get things started is enough to get you binaries that correspond to the sources and nothing else. it is nice to be able to verify that there aren't invisible blobs, but such verification is not essential for software freedom, only to show that a certain binary contains a hidden blob (I hope the distinction is clear and meaningful, and not taken as demeaning either one). the verification is made easier and mechanical by having both a free bootstrap path and reproducible builds, but really, starting from two known-independent compiler binaries, using one of them at a time to bootstrap the free compiler that is then used to build the desired program may very well be enough to verify the absence of hidden blobs, provided that the initial compilers are indeed independent, and that the hopefully-free bootstrapped compiler does not borrow library code from them. reproducible builds, of the compiler and of the program compiled by it, would likely help notice in case they do.
But GCC's bootstrapping binaries are in contrast to providing the freedom to study how the program works, or being able to change it however you wish. Mystery goop that is required to build the software that builds your operating system and the programs that run on it is a dilemma for free software. It took years of work to solve, and now that it has there is no good excuse for shipping bootstrapping blobs.
@amszmidt@vagrantc@ekaitz_zarraga@loke how is shipping mysterious bootstrapping binaries to users not concerning regarding their freedom, especially given that Ken Thompson first became aware of the trusting attack via Air Force research?
This isn't to downplay the work of the free software movement, because this is a advancement of the free software movement. It strengthens and upholds all the advancements of the free software movement's past. But to assume that software freedom has existed in some static sense, rather than seeing software freedom as a continuous struggle towards the guarantee of freedom for *all* computer users, which will always remain a concern insofar as people are computing, I think is mistaken.
Bootstrappable builds advance users freedom significantly, and sets a higher standard of what qualifies as essential for ensuring your users freedom. Reproducible builds sets a new bar for how software should be distributed, and I do not believe that every software user needs to be taking the time to build their entire stack from source (but everyone who wants to should remain able to, of course). The combination is elegant and reasonable; one doesn't need to be a scientist to become confident in how things work after a bit of study. Delivering source code with a make script is subpar when the user has no means of auditing the compilers complete source.
@rml@vagrantc@ekaitz_zarraga@loke read the four freedoms and you will see why: understanding software is not a software freedom. It is also not an advancement, it makes things more complicated. This is diluting the message of why software freedom exists and is important. We have much harder taks to tackle than technical solutions. Even basic manuals are more important than RB&B.
@vagrantc @janneke@todon.nl @ekaitz_zarraga@loke no, they really do not. Stop this nonsense. Software freedom is not dependent on RB or bootstrappable builds any more than it is dependent on ASAN or a GC. They are purely technical features which have literally nothing to do with software freedom.
though you probably already know the answer, I'll risk responding: (0) running the program for any purpose, and (2) making verbatim copies of the program and distributing them when you wish. no relationship with bootstrapping or reproducible builds, or even with building, but essential for one to not be placed under duress by unjust and impractical constraints, nor to be required to be a bad community member
@amszmidt@rml@vagrantc@loke The source code is not the only relevant thing in the free software. Access to the source code is only a precondition in 2 of the 4 freedoms. If the source is the only relevant thing, what are other freedoms talking about?
@rml@vagrantc@ekaitz_zarraga@loke tanget. Binaries are unrelated to the four freedoms. You need source code for something to be free. The binaries are entirely irrelevant.
in case you haven't seen my response to blake in this thread, you may want to look for it and read it before what follows
if your compiler inserts hidden blobs that are not present in its source code, then you're not using a free compiler, right? whereas if you start from fully-free tools, whatever you build with them from free sources should also be free.
verifying only comes into play if you wish to take shortcuts by using binaries supplied by third parties that can't be assumed/trusted to be free. and if they can't, and verification involves *not* taking the shortcut, it's not much of a shortcut, is it? :-/
@amszmidt Not really because the only way you can make sure my compiler doesn't have the backdoors is making sure the source of the compiler is the one it claims to be.
And if the compiler needs to be compiled, the previous problem repeats. How do you know the compiler that compiled the compiler didn't introduce backdoors?
@amszmidt Yes, but the problem comes when you are not aware that feature is there. If your compiler introduces those things against your will, the binary you produced is not free. As you can't have the source for what you are running.
When I say we analyze this problem from a practical perspective is the following: think about a modern C program. You need a compiler to build it, say GCC. You distro gives you a compiled version of that software claiming it is free. How can you know it is free? You can only blindly trust your distro... If your distro's maintainers act with good faith, it may still happen their compiler is corrupt. How do you know if it is?
@ekaitz_zarraga I know if it is free if I can exercise the four freedoms for that particular program. Being able to compile it is not a pre-requisite. Being given a binary is not giving someone a free program.
Something being corrupt (i.e. being buggy) or not is irrespective if something is free or not.
@rml@vagrantc@ekaitz_zarraga@loke And nobody hsa really argued anything else. Just like the GNU GPL imposes some extra stuff on being able to know how to build the program.
But that too .. is not related to software freedom, but making sure that the gap between one party and the other is made non-existent, e.g., see DRM in GPLv3 to make sure that those who can make a signature, also much allow others to _chive_ the same thing.
@rml@vagrantc@ekaitz_zarraga@loke And similarliy, SaaSS is also not related to software freedom. Just harmful to users, since you loose control of your computer.
SaaSS can still be free software, and a bad idea...
@rml@vagrantc@ekaitz_zarraga@loke and no good excuse? What a dismissive claim … you’re essentially saying that one should not be able to modify a program anyway one wants to. E.g by having non bootstrapable or non reproducbale software. This is the same thing that the anti-ethical crowed is spreading…
@amszmidt@vagrantc@ekaitz_zarraga@loke I think people should be able to have whatever kind of software they want, insofar as they arent imposing it on others. My issue is with software distributors, and even then I dont trust states and their police forces to determine how and what can be distributed. I just think its the duty of free software activists to innovate and improve the state of free software, and several mb of mystery blobs is several mb of software where the freedom to study a program and change it so it does your computing as you wish remains unfulfilled.
With GNU Mes and Guix users are free to do all the fun, silly and deranged things we can conceive of with our software. All there is is the text, for you to modify and have fun with, and I think thats beautiful.
hmm, we may have miscommunicated. knowing that two compilers (or two toolsets) are *independent* is no simple feat indeed, for all the reasons you named, and then some. e.g., many many years ago, gcc used to borrow (by bringing into libgcc) implementations of long integer and float operations from whatever compiler you used to build it. this was a clever trick for native builds (not so much for crosses), but it have the side effect of building blobs of unclear provenance into libgcc, and thus potentially into binaries built by the compiler, and that's very down-to-earth, mean-no-ill behavior (as opposed to malicious esoteric attacks), but it is undesirable for various reasons.
now, since we're talking software freedom philosophy rather than security issues, please allow me to bring some further thoughts onto the table. if you're writing, compiling, debugging and fixing a program so that it does your computing as you wish, and not once do you notice these hidden blobs, or hit a situation in which they'd be activated so as to deviate the program's behavior from what's expected from its sources, are you not getting your computing done as you wish regardless of the hidden blobs? are you not indeed in control of that computing? there are some security risks and landmines hiding in there, I'm not denying that, just trying to un-conflate freedom and security.
so the hidden blobs pose an obstacle to learning details of the binary, but to studying the source code?
@lxo I don't think its so simple as starting from two independent compiler binaries. with Thompson's attack, the trick was of course a matter of introducing changes to what constitutes legal C code in phases, so that a seed compiler has been "trained" to interpret the backdoor of an attacker as legal C code, and that "knowledge" is then propagated from binary to binary, without the user's knowledge. and its not just GCC, but also coreutils, binutils, glibc and others that make up around 200mb of boostrap binaries on any given free operating system distribution. if you recompile these tools with pcc or clang, from source and then again with GCC, all coming from different distributors, you're just assuming that one of compilers breaks the chain of the attack. but nothing actually suggests that, considering those tools are all similarly built from blobs that may contain generational backdoors. you have to trust not only your source, but whatever they trusted as well.
"bootstrap" is an overloaded term, with two relatively similar meanings. in that context, I meant the way it's used in compiler development, i.e., having the compiler go through stages of compiling itself and comparing outputs as part of its regular (native) build process, for verification purposes
"Do you know how to make yoghurt? The first step is to add yoghurt to milk!" (and no worries, this also holds for/we're probably talking about soy-based yoghurt")
Either your "local bootstrap" is not a bootstrap at all and you've been injecting binaries downloaded from the interwebs. Even if you ran some parts of its build process actually building some things from source with those binaries, what could be the use of that? After all, the easiest way to not-bootstrap a program is to just download it in binary/runnable form right away.
Or, you have (possibly freshly created) a bootstrap for the program, but haven't shared it yet, and thus the program is (or you just made it) "bootstrappable" and it is truly (eligible to be) free software, and we now may exercise "freedom 0".
@lxo And trust in a very very very narrow sense -- the programs you install might still be malicious, buggy, or otherwise riddled with unwanted behavior.