-
Notifications
You must be signed in to change notification settings - Fork 1
Add github release workflow for reproducibly-built debian package #76
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
base: main
Are you sure you want to change the base?
Conversation
* main: Remove check enforcing client auth with client attestation Allow no client auth
Cargo.toml
Outdated
| inherits = "release" | ||
| lto = "thin" | ||
| panic = "abort" | ||
| codegen-units = 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not all projects would require the codegen-units = 1 to be reproducible. I added this to the Reth code-base because it was the only way to make the build reproducible but it comes at the cost of build time. Meanwhile, I was able to make lighthouse build reproducible without it (see PR).
You could try using the release profile and see if despite the reproducible flags you are setting in the makefile, it still produce the same hash or a different one upon two subsequent fresh clean builds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok - i removed this and still get the same .deb file on two subsequent builds without docker cache - but not sure if there is a more rigorous way to check for reproducibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question, usually I try to fresh build the binary/deb on 2-3 different host machines with slightly different setup and hardware specs to double check if all end up with identical hashsums. I compare them also with the results of github workflows.
We could also have something similar to flashbots-images where we create a lima build env to emulate the setup config but that might be a bit overkill.
Maybe @bakhtin has a middle solution that fits the purpose here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
usually I try to fresh build the binary/deb on 2-3 different host machines with slightly different setup and hardware specs to double check if all end up with identical hashsums. I compare them also with the results of github workflows.
Good idea.
We could also have something similar to flashbots-images where we create a lima build env
Im not so into lima because of the difficulties of using it in CI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in case it is helpful for you, here is a draft PR where I am adding reproducible debian packaging to lighthouse
| @@ -0,0 +1,14 @@ | |||
| #!/usr/bin/env bash | |||
|
|
|||
| # Checks reproducibility by running a package build twice and printing hashes of .deb package | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Im not sure to what extent this really shows that the build is reproducible, but its better than nothing
This copies the workflow for debian packaging from rbuilder:
TODO:
Here is a test release built on this branch:
https://github.com/flashbots/attested-tls-proxy/releases/tag/vtest00