Unfortunately many open source applications are not reproducible, which means that their is no practical way to prove that the published binary is actually the result of compiling the published source code.
If we can’t confirm that the binary is actually matching the source code, then the maintainer could just add something malicious and compile it into the application without people noticing it, even if they check the source code.
So my question is, are none-repreducible FOSS apps even more trustworthy then their proprietary counterparts, or do we still need to put blind trust into the publisher like with closed source apps?
Not if you download the binary from the developer. But I think the logic is that if you do trust the dev to not be malicious, then open source code can let you find bugs and vulnerabilities and report/fix them more easily. But yes I would like to see more reproducible builds in FOSS software.
It should be one of the core tenets of FOSS development, unwritten rule taken with seriousness that should be bound by one’s ethics given the nature of the work.
That I download the binary from the developer doesn’t neccessary mean that its reproducible.
Often times if you want a reproducible build you go for a binary compiled by an intermediary like F-Droid, because they try to make every bianry reproducible.
Or dou I get you wrong there?
Yes, this are still valid points.
I also could take the Open Source code and make reproducible builds out of it and then redistribute them.
Yes, I see no reason do not make your open source builds reproducible.
I also think that platforms like Flathub should only give the Auditable code security flag to applications that are actually reproducible and therefore auditable.
Developers like to use a lot of third-party components to make their lives easier. Everything included has to be reproducible for the resulting package to be reproducible as well. That is one possible reason.
It looks like @fria meant to say that non-reproducible FOSS apps are no more trustworthy than proprietary apps, not that we don’t need to put blind trust into publishers just like with proprietary apps.
My understanding is this, please correct me if I’m wrong. Binaries built from non-reproducible FOSS code are not much more trustworthy than binaries built from proprietary code. Without reproducible builds, some verification between the binary and source code is possible in the FOSS case, but there will always remain the possibility the developer (or more accurately whoever builds the binary) secretly modifies the source code before building or perform other secret modifications to the build.
Reverse engineering could detect some modifications, but I wonder how often it is done in practice, and people can’t be expected to reverse engineer all the apps they install. I’m unfamiliar with laws but it’s also possible that reverse engineering is illegal in some jurisdictions, though more likely with proprietary software than FOSS I guess.
Depends on what you mean by “trust”. Even with reproducible builds, there’s a bunch that you still must implicitly trust, namely the build server software, the build system, the compiler / interpreter etc. This is without even going in to the details about the trust worthiness of the supervisor (kernel) or the hardware (cpu etc) that runs the code.
That said, reproducible builds are a step in the right direction, and the path to full reproducible builds is a wild ride from here till the finish. Debian is one such project that intends to get there. If you’re technical, ref this write up by folks at GNU/Guix (The full-source bootstrap), and this rather long / on-going F-Droid discussion.
Reproducible builds aren’t the only solution to this.
If the code is public and the build server logs are public, then with build provenance and software bill of materials attestations, the developer can claim a “F-Droid like” guarantee (that the build output / artefacts / binaries were built by a particular publicly-visible build run). As a concrete example, for build outputs of GitHub Actions on public (and open source) repositories, GitHub can attest if the binaries (and the dependencies that the binaries were build with) you’re looking at is the one that a particular build run (GitHub Actions workflow run) built.
Speaking of FOSS I develop: Attestations (link) of both the build and the dependencies is key to proving that a particular firestack[1] version has indeed been built from source (as it is vended out by Maven Central OSSRH and not built by F-Droid).
We also intend to deploy attestations for the server-side code we built on and deployed by GitHub Actions for our DNS resolvers at max.rethinkdns.com.
It isn’t because FOSS developers are lazy or malicious. This is inherently a difficult problem (:
The networking and wireguard library behind Rethink DNS + Firewall ↩︎
Hm. Will you be more specific: What “guarantees” do reproducible builds provide that attestations don’t?
The primary concern for folks behind reproducible builds (link) is:
… to allow verification that no vulnerabilities or backdoors have been introduced during this compilation process …
… which they seek to accomplish by doing:
… promising identical results are always generated from a given source … allows multiple third parties to come to a consensus on a “correct” result, highlighting any deviations as suspect and worthy of scrutiny.
While provenance attestations on GitHub (doc, blog) achieve:
… unfalsifiable provenance and integrity guarantees for the software you build. In turn, people who consume your software can verify where and how your software was built.
… create a tamper-proof, unforgeable paper trail linking their software to the process which created it.
Fascinating topic. In this scenario of reproducible FOSS applications, how do you feel about situations like the following?
In the Arch official repo current Firefox (firefox 145.0.2-1) doesn’t seem to be reproducible, where the Firefox developer edition is (firefox-developer-edition 146.0b9-1).
Yep. Secureblue seems to be super serious about software supply chain security (sifting through their GitHub to see what I can setup for my projects), so cc: @RoyalOughtness
Strictly from a security-perspective, what useful properties and trustworthiness does this provide? Other than maybe mitigating only a slice of potential targeted attacks against the maintainer/authors build tools and environment.
If I understand correctly, binary transparency does not require that source code is shared with independent builders. It would also let people verify that they haven’t been specifically targeted with a malicious binary.
Then the application is not fully open source.
And if you use GPL licensed code, this would be a violation of the GPL.
Yes, without reproducibility, we can’t verify that the binary is matching the source code.
Reverse engineering of open source apps is always legal and in jurisdictions like the European Union you can even legally reverse engineer proprietary software for private-use/research purposes.
But If the only means of verification is reverse engineering, then we are at the same position then with proprietary software, considering verification.
Does this mean it verifies that the binary corresponds to the source?
And can this be verified by anyone (who understands the basic about code compilation) ?
Speaking of Reproducible Builds, even those don’t “mean” the thing ONLY corresponds to the source it was built from. The only surest way (I know) of guaranteeing that the thing is built from source is to build everything that builds the thing and everything that the thing needs … be built from source (see my point about “boostrapping builds” above).
Yes, as all “attestations” are transparently recorded in an immutable, publicly-accessible log (similar to Certificates that power TLS on the Web). There’s many 3p verifiers (ex: this one by Google) as well as a first-party verifier (by GitHub).
Its better to be forced to put some trust in the build environment and the operating system then to put trust into every application that has access to any critical data or permissions.