You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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: