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