Reproducible builds

[hinto-janai]

What

This is a request for comment on reproducible builds for Cuprate.

Similar to https://github.com/monero-project/gitian.sigs, this would allow anyone to deterministically build Cuprate binaries.

This process would also be used for the public release binaries (as Monero does).

Assuming this should be focused on, it still may be very far out - this work would be done around the time Cuprate is ready for a stable public release.

How

An incomplete list of some steps that could be involved.

---

cargo vendor

The source code for the entire cargo dependency tree be fetched and stored locally with:

cargo vendor

which stores all dependencies within vendor/.

After editing the projects .cargo/config.toml to:

[source.crates-io]
replace-with = "vendored-sources"

[source.vendored-sources]
directory = "vendor"

cargo build would build using the local files.

This may not be needed, depending on the below.

---

Semantic Version

Source versions could be controlled.

In all of Cuprate's Cargo.toml files, we must use one of:

• A fully specified version v1.0.0, not v1
• Specific commits to dependencies

This applies to all crates within Cuprate and external submodules, not just the root workspace Cargo.toml.

Committing the Cargo.lock with these specific versions would guarantee people are building the exact same dependencies (with the caveat being yanked crates).

---

Build System

Any data used in the build process outside of the Cuprate tree and/or dependent on the build system must be accounted for.

Notably:

• System libraries
• cfg!(target_os = "windows/macos/linux/etc")
• Input/output of system-specific build.rs scripts

The same gitian process Monero uses could be used for this.

[kayabaNerve]

https://github.com/serai-dex/serai/blob/develop/orchestration/runtime/Dockerfile is a direct Dockerfile, no gitian needed, to create a deterministic environment.

An additional note I have to contribute is host architecture will impact the build process.