Skip to content
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

Open
wata727 opened this issue Apr 11, 2022 · 2 comments · May be fixed by #2159
Open

Keyless signing #1351

wata727 opened this issue Apr 11, 2022 · 2 comments · May be fixed by #2159
Labels
enhancement needs-design Detailed design is required for implementation

Comments

@wata727
Copy link
Member

wata727 commented Apr 11, 2022

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.

@mitchellrj

This comment has been minimized.

@wata727
Copy link
Member Author

wata727 commented May 5, 2024

GitHub recently introduced Artifact Attestations.
https://github.blog/2024-05-02-introducing-artifact-attestations-now-in-public-beta/

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.
https://github.com/cli/cli/blob/v2.49.0/pkg/cmd/attestation/verify/verify.go

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement needs-design Detailed design is required for implementation
Development

Successfully merging a pull request may close this issue.

2 participants