# Reproducible builds for rustc: GSOC '25 idea **URL:** https://internals.rust-lang.org/t/reproducible-builds-for-rustc-gsoc-25-idea/22532 **Category:** Uncategorized **Created:** [March 10, 2025, 11:16am UTC](https://internals.rust-lang.org/t/reproducible-builds-for-rustc-gsoc-25-idea/22532 "2025-03-10T11:16:49Z") **Posts on this page:** 5 **Page:** 1
### Author: ![ritesh](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ritesh/32/13038_2.png) [@ritesh](https://internals.rust-lang.org/u/ritesh) #### Post date: [March 10, 2025, 11:16am UTC](https://internals.rust-lang.org/t/reproducible-builds-for-rustc-gsoc-25-idea/22532/1 "2025-03-10T11:16:49Z")
Previous discussion (2016) : [Verifying rustc releases with reproducible builds](https://internals.rust-lang.org/t/verifying-rustc-releases-with-reproducible-builds/4502) I'm creating this topic to share my understanding of the problem and what approaches are available to potentially try and build this capability. I would also like to understand if this is _worth_ doing as I don't have a handle on the complexity of the problem or dependencies that sit outside the rust source tree that could affect reproducibility. By reproducible build of rustc I mean that if I gave you a copy of the rust source archive and gave you the details of my build environment and build steps that were used to create rustc, you should be able to create the same (i.e. bit-for-bit) rustc. This addresses the problem of whether I, as a compiler distributor, can be trusted and that my build environment does not accidentally or maliciously insert code or functionality that was not present in the rust compiler source. As a user of rustc, you (or other independent 3rd parties) can verify that my (distributor of rustc binaries) build process is beyond reproach. However, note that having a reproducible build makes no assurances about the code of the rustc compiler itself. Hypothetically, if someone inserted a malicious backdoor in the source code of the rust compiler (or a library that it depends on) - having a reproducible build will not fix the issue. The assumption is that the source code for the rustc compiler has already been reviewed by other means. A number of folks have already done some work in this area (see: [Testing out reproducible builds - The Rust Programming Language Forum](https://users.rust-lang.org/t/testing-out-reproducible-builds/9758)). Sadly the test bench referenced in the discussion is no longer available. More discussions here: > > > Reproducible builds would be useful for a number of different reasons: > > \- Bina…ry releases of Rust applications which can be independently verified for reproducibility > \- \[Binary crates\](https://github.com/rust-lang/cargo/issues/5654) > \- A community build system / \[global build cache\](https://internals.rust-lang.org/t/idea-cargo-global-binary-cache/9002) > > I believe the main issue for reproducible Rust builds in general is: > > https://github.com/rust-lang/rust/issues/34902 > > Right now it seems like some people are able to successfully use the following tool to test for reproducibility of Rust builds in CI: > > https://pypi.org/project/reprotest/ > > I'm curious if it would make sense to build a Rust-specific tool for this purpose, particularly one that integrated with cargo workflows and can both drive reproducible builds and check them, either in CI or as part of an auditing service. Something like \`cargo repro\`, maybe with a \`cargo repro build\` and \`cargo repro check\`? > > > At a high level, the goal of this project is to make it easy to develop software… in Rust which, when compiled, can be independently verified to determine that a given binary was produced from a particular source code input. > > To accomplish this, compiling Rust code must produce byte-for-byte identical results given a particular source code input, allowing multiple third parties to come to a consensus on a “correct” result. > > How exactly this should be accomplished is debatable, and this issue is a place to discuss potential designs. > > See the previous Secure Code WG issue on this topic for more background: > > https://github.com/rust-secure-code/wg/issues/28 > > \## Prior Art > > \- \[reprotest\] (Python): reproducibility testing tool > \- \[diffoscope\] (Python): binary diffing tool > > \[reprotest\]: https://salsa.debian.org/reproducible-builds/reprotest > \[diffoscope\]: https://diffoscope.org/ The Debian project has a set of tools (reprotest and diffoscope) that can help with checking how changes in environment, date/time, filesystem ordering, etc. affect a build process. The tooling is Debian/Linux specific and I currently don't have access to a beefy Linux instance to test it. In my initial testing on macOS, I couldn't get reprotest to work as it looks like it has a hard dependency on dpkg, even if you're not building Debian packages. So I don't know if this fits the criteria for a GSOC sized project since there's a whole lot that I don't know - but it's an interesting problem that I'd like to tackle starting with Debian as it has infra to test for this already. 1. Get a beefy Debian box, figure out _if_ it is possible to get repro builds for rustc by making changes to the build process 2. If we learn that the changes to the build process can make builds reproducible - propose to add them in 3. Want to figure out if changes to make builds reproducible will apply to macOS, other linuxes 4. Tackle MS Windows (this would be the most daunting task, personally I have no experience here but I think there are lots of people interested in getting this done!) 5. If we learn that this is not possible _today_ (e.g due to the way LLVM is used or something), figure out what it would take to fix it - and weigh in on whether it is worth fixing Would love to hear from folks who have already done some work in this area or have experiences to share from making builds reproducible. ---
### Author: ![bjorn3](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/bjorn3/32/2736_2.png) [@bjorn3](https://internals.rust-lang.org/u/bjorn3) #### Post date: [March 10, 2025, 12:43pm UTC](https://internals.rust-lang.org/t/reproducible-builds-for-rustc-gsoc-25-idea/22532/2 "2025-03-10T12:43:42Z")
Just to link back to the zulip thread: [#gsoc \> Idea: reproducible builds](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Idea.3A.20reproducible.20builds) ---
### Author: ![pitaj](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/pitaj/32/11262_2.png) [@pitaj](https://internals.rust-lang.org/u/pitaj) #### Post date: [March 10, 2025, 1:49pm UTC](https://internals.rust-lang.org/t/reproducible-builds-for-rustc-gsoc-25-idea/22532/3 "2025-03-10T13:49:43Z")
I'm what way(s) are rustc builds not already reproducible? ---
### Author: ![ritesh](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ritesh/32/13038_2.png) [@ritesh](https://internals.rust-lang.org/u/ritesh) #### Post date: [March 10, 2025, 2:23pm UTC](https://internals.rust-lang.org/t/reproducible-builds-for-rustc-gsoc-25-idea/22532/4 "2025-03-10T14:23:44Z")
I have not done an exhaustive review yet - but testing by Arch Linux - [https://reproducible.archlinux.org](https://reproducible.archlinux.org) (search for rustc on this page) and debian trixie [rustc - reproducible builds result](https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/rustc.html) appear to indicate that the build process for rustc is not-deterministic and hence not reproducible (at least for those platforms). As folks have pointed out, this is a separate concern from whether cargo produces reproducible artefacts or not. ---
### Author: ![RandyMcMillan](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/randymcmillan/32/11595_2.png) [@RandyMcMillan](https://internals.rust-lang.org/u/RandyMcMillan) #### Post date: [December 5, 2025, 12:53pm UTC](https://internals.rust-lang.org/t/reproducible-builds-for-rustc-gsoc-25-idea/22532/5 "2025-12-05T12:53:26Z")
important work - thanks.