-
Notifications
You must be signed in to change notification settings - Fork 3
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
Improve Dockerfile #4
Conversation
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.
Thank you for the PR!
I did indeed notice that the signing keys need to be updated with every release.
Your change works well, I've tested it locally.
But, I'm not sure if it's a regression in terms of trusting a single repository (and GitHub for that matter) with the "truth" about the signing keys. Sure, we're talking about docker images where the final layers currently aren't cryptographically verified (since we're only doing this check at build time not at run time).
But still, I think having the keys hard coded kind of makes it easier to detect irregularities with signing keys which IMO outweighs the issue of needing to update a few keys every 6 months.
Curious to hear what you or others think.
Im not sure if it will make it harder to detect irregularities, since all the key will be printed to (and stored by) the workflow log when running the build. So I see it more as moving the keys from the Dockerfile to the workflow log. You dont loose any traceability. |
What I mean is: When we add a new version, we (or at least I do it that way) usually start by copying the code from the previous one, then running it locally. This would fail if new signing keys were used, so we'd need to add those one by one. And I personally would get suspicious if suddenly there were a lot of new signing keys needed to validate the build. Then I would have a reference of key IDs to compare things to and judge whether something weird is going on. But I guess we're splitting hair here. I'm okay with either approach. |
@calvinrzachman and @djkazic curious to hear your opinion on the discussion above. |
I feel more comfortable having the keys in the dockerfile |
@djkazic: review reminder |
The current way how the Dockerfile does the signature checking (by hardcoding the keys) is very error-prone because those keys change every release.
Therefore I implemented an automatic retrieval of the keys from the official
bitcoin-core/guix.sigs
repository. So that for every version the correct keys are retrieved.