Authenticate releases using the embedded verification key. #192
Conversation
PiotrSikora
force-pushed
the
verify_signature
branch
from
6ed0581
to
11d9b32
Compare
|
@philwo PTAL |
Fixes bazelbuild#15. Signed-off-by: Piotr Sikora <piotrsikora@google.com>
PiotrSikora
force-pushed
the
verify_signature
branch
from
11d9b32
to
a9b338f
Compare
|
Sample output: |
|
Thank you @PiotrSikora! I was on vacation - will look into this PR this week! |
|
@philwo friendly ping. |
|
This looks really nice, thank you! It's great that we don't need to call The only thing I'm wondering - what will happen when the embedded key expires? In the past this meant we had to extend the key and then everyone had to reimport the extended one into their GnuPG keychain (see https://groups.google.com/g/bazel-discuss/c/XzeKUSkMCDk/m/GiOj6ariEgAJ for some former discussion). Would it mean that older Bazelisk releases will suddenly fail to fetch Bazel releases until we update the embedded key and users update to a newer version? 🤔 |
Effectively, yes. They could always update Bazelisk to get the new key, or you could embed multiple public keys and do a rolling update, but that requires knowing the "next" key ahead of time. A bit longer solution would be to redesign the signing infrastructure to use subkeys for signatures and rotate it periodically (see: https://www.gnupg.org/gph/en/manual/c481.html) and have the primary key without expiration date. It doesn't really serve anybody if the primary signing key is changed every year or two. |
|
Thanks for the explanation! Unfortunately we're deep in "I have no idea what I'm actually doing here, except copy & pasting various GnuPG command-lines from the internet and hope they will fix whatever is broken" territory when it comes to our code signing stuff and every time I have to extend the lifetime of the key, I just hope it doesn't break everything. 😬 I'll read up about GnuPG best practices in the next weeks, something I always wanted to do. If it's OK with you, I'd leave this PR open just a bit longer, while I figure out how we want to handle our signing key - from the code and feature side, this is very much great and ready to merge imho :) Thank you for this! |
|
Yeah, no rush. |
|
@philwo friendly ping 😄 |
|
@philwo ping. |
|
As independent verification I rebased this patch against v.11.0 and it works: The only real change was |
…signature Signed-off-by: Piotr Sikora <piotrsikora@google.com>
| } | ||
|
|
||
| if len(keys) != 1 { | ||
| return "", fmt.Errorf("failed to load the embedded Verification Key") |
There was a problem hiding this comment.
Thanks for putting this together, @PiotrSikora! We'd love to leverage this too.
Three ideas for handling an expired embedded key:
- Add an error message on failure (bonus points for specifically looking if the key is expir,ed) pointing users to look for a new release since the embedded verification key may be expired.
- Add a
--no-verifyflag to skip verification entirely 😅 - Add a
--verification-signature-fileflag as a "break glass" method to use a different key, which folks can use to pull from a fork.
Before adding those workarounds, it'd likely be better to avoid the complexity if possible! If there's anyone who won't be able to upgrade bazelisk to get a new key, it'd be great to hear about that use case! The only actual caveat I can think of is remembering to upgrade this tool every N years with the new key, but that's well worth the tradeoff to me! 🎉
Fixes #15.
Signed-off-by: Piotr Sikora piotrsikora@google.com