-
Notifications
You must be signed in to change notification settings - Fork 20k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release-pipeline: reproducible builds #18292
Comments
To be clear, reproducible builds have been possible for a long time. The only requirement is that the source be checked out to the same directory. The Go issue you linked is discussing an idea to remove even that restriction. |
yea - but on CIs you often do not have full control over the paths - hence I was writing possible/easier |
might in the process dogfood Cryptoeconomic Release & Version Control |
i have tried to reproduce the released geth binary, but it seems to be a far fetch, at least with a simple invocation of
is there any update/summary of the deterministic build situation? context: i'm working on the Guix packaging of geth, and i was hoping that i could set up something that downloads and authenticates the official release binary, then builds geth locally, and compare the two. is that feasible at this point? |
i have opened a PR to set the buildid to a fixed (empty) string: #23527. with that, the resulting binary is reproducible. EDIT: this^ is wrong, or half-true. follow through to the PR if interested. |
Thanks for caring for reproducible builds! |
a proposal for terminology; this may be of interest here: Reproducibility vs. Replicability: A Brief History of a Confused Terminology TL;DR:
|
on a related note: i have installed Guix as my daily driver, and it is an excellent tool to host replicable builds. the distro's repo is a git repo, and it's possible to ask for a shell environment by pointing to a specific commit of the Guix git repo. building on top of Guix, a project can have everything specified in its build scripts for replicability, even several years later. and the icing on the cake is that the binary seed for bootstrapping Guix itself (which is of course reproducible build) is now very tiny (IIUC a couple hundred bytes called HEX0, which fits into a boot sector). |
for inspiration: Feather wallet uses Guix for reproducible build. |
Closing this issue. Unsure where we are on this, but it's not something we're actively trying to address so cleanup time. |
We should reduce our trust into travis
Ideally we should build on travis and another platform (can also be a local dev machine) and then compare the binaries. Only if the binaries match -> do/sign the release
Reproducible builds might get possible/easier with Go 1.13 - golang/go#16860
The text was updated successfully, but these errors were encountered: