-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Provide tarballs for offline-builds #3195
Comments
Hey, thanks for bringing this up! We generally agree that reproducible builds are something that go-ipfs should be capable of.
It's usually just fine to include hashes with every external source you fetch. I'm wondering what the reasoning is to forbid fetching things from the network? Is it to allow fully offline builds? I think that's a different matter from reproducibility.
I disagree -- instead of bundling/vendoring everything, we should aim for complete verification of all dependencies. Using Gx is already a great step forward, but we should aim to have all our dependencies stored in IPFS, so that we can address them with a single multihash. Note that IPFS provides self-authenticating data structures, which solve a big part of the problems on the way to reproducible and verifiable builds. |
That's fine for us, iff Is it possible to use |
I'm not sure it is right now, and what the state of reproducible builds with Golang generally is at the moment, but yes it should. Only changes of package.json or Golang should result in different binaries.
The dependencies are specified in package.json and Anyhow, please let us know however we can help! :) To my knowledge you'd be the first to roll reproducible builds of go-ipfs and there's probably a lot we can learn from and improve. |
Lars Gierth [email protected] writes:
That's nice to hear! We'll see if go causes problems. As far as I know
That's very good! The last time I tried to package a recent version of
Getting rid of downloads (or other network access) in the build goes a Thanks! |
@the-kenny If you want, you can do a In the future we want to add in the ability to select a specific compiler through gx, meaning that everyone who builds ipfs at a certain version wouldnt just get the same source, but the same compiler and all dependencies, which if i'm not mistaken (i.e. go doesnt have weird timestamps in the build process) should result in a fully reproducible build. |
I recall issue with Golang where as the compilation and linking process are performed concurrently the order or symbols in binary wasn't stable but it might have changed. Also there is problem with build paths: golang/go#16860 but this could be solved by building in chroot, I think. |
I'm confident golang will get to fully reproducible builds, if it's not Would be great to start packaging go compiler itself with gx so that @the-kenny thanks for work on this. Bonus points if you use We probably should have a tool like
|
Looks like golang builds themselves are reproducible:
I did remove the pkg cache after the 2nd one. |
Resolved by #4920 |
Type: feature
Area: build
Many distributions try to switch to fully-reproducible builds for their packages. Fetching stuff from external sources (ipfs, http, git, etc.) is a no-go in such situations. Some package managers like Nix even go as far as blocking all access to resources outside the specified bounds (including network access).
It would be helpful if
ipfs-go
could provide tarballs which include everything necessary to buildipfs
, including all dependencies that would be fetched over the network in a normal build.The text was updated successfully, but these errors were encountered: