-
Notifications
You must be signed in to change notification settings - Fork 347
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
Keyless signing #1351
Labels
Comments
wata727
added
needs-design
Detailed design is required for implementation
enhancement
labels
Dec 28, 2022
Open
This comment has been minimized.
This comment has been minimized.
GitHub recently introduced Artifact Attestations. It may be a good idea to introduce the attest-build-provenance action into the plugin repository and implement a verifier in TFLint like the GitHub CLI. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm a fan of keyless signing ideas. In TFLint, we distribute signatures and a public key to verify that the release was created by us. This private key only exists in my local machine, so an attacker cannot replace it with a malicious binary unless my computer is compromised.
On the other hand, It's not good that only I can sign. Ideally, committers should always be able to create releases with valid signatures. However, sharing a private key has long been a headache for me because it makes key management problems.
Keyless signing solves this problem. If you can use the GitHub Actions OIDC provider and confirm that the token is issued from the appropriate repository, you can verify that the release is created by us. Certificates are stored in Rekor, so you don't even have to think about managing public keys
This idea could also be used to verify plugins. We are currently embedding the public key in TFLint for major ruleset plugins such as tflint-ruleset-aws to ensure that the plugin is distributed from the appropriate repository. For other third parties, you need to put a long
signing_key
in the config file. With keyless signing, users can use signed and secure binaries without any additional configuration.However, the problem with this way is that it is vulnerable if an attacker gets the namespace after the owner renames the repository. An attacker-signed release in this way is indistinguishable from an owner-signed release because the OIDC subject claims only contain the repository name.
A mitigation for this problem is to generate a file that stores the checksum, such as
go.sum
. I believe that this will allow us to adopt keyless signing.The text was updated successfully, but these errors were encountered: