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
When a certificate is disabled, I expected the verifier to fail because only enabled certificates should pass verification.
What version of Kubernetes are you running?
1.28.3
What version of Ratify are you running?
v1.3.0
Anything else you would like to add?
This issue arises when a Key Management Provider (KMP) is configured with a certificate that is enabled at the time of the KMP resource's creation but later becomes disabled. If a new certificate version is created and no version is specified in the KMP resource spec then the issue resolves when the new (latest) certificate is added to the cert/key maps. However, if the old version is specified in the spec it will still pass verification because it's never removed from the map and it still has a valid public key from the cert stored.
To fix this, I'd suggest adding logic to purge the cert\key maps when the AKV provider encounters a disabled cert or key.
Are you willing to submit PRs to contribute to this bug fix?
Yes, I am willing to implement it.
The text was updated successfully, but these errors were encountered:
What happened in your environment?
Ratify is using a disabled certificate to verify notation signatures.
What did you expect to happen?
When a certificate is disabled, I expected the verifier to fail because only enabled certificates should pass verification.
What version of Kubernetes are you running?
1.28.3
What version of Ratify are you running?
v1.3.0
Anything else you would like to add?
This issue arises when a Key Management Provider (KMP) is configured with a certificate that is enabled at the time of the KMP resource's creation but later becomes disabled. If a new certificate version is created and no version is specified in the KMP resource spec then the issue resolves when the new (latest) certificate is added to the cert/key maps. However, if the old version is specified in the spec it will still pass verification because it's never removed from the map and it still has a valid public key from the cert stored.
To fix this, I'd suggest adding logic to purge the cert\key maps when the AKV provider encounters a disabled cert or key.
Are you willing to submit PRs to contribute to this bug fix?
The text was updated successfully, but these errors were encountered: