chore: removed TODOs, updated outdated specs etc #231
Conversation
Signed-off-by: Pritesh Bandi <pritesb@amazon.com>
priteshbandi
changed the title
priteshbandi
changed the title
specs/trust-store-trust-policy.md
Outdated
| @@ -206,7 +210,7 @@ The following table shows the resultant validation action, either *enforced* (ve | |||
|
|
|||
| **Revocation check** : Guarantees that the signing identity is still trusted at signature verification time. Events such as key or system compromise can make a signing identity that was previously trusted, to be subsequently untrusted. This guarantee typically requires a verification-time call to an external system, which may not be consistently reliable. The `permissive` verification level only logs failures of revocation check and does not enforce it. If a particular revocation mechanism is reliable, use `strict` verification level instead. | |||
|
|
|||
| - **NOTE** : `notation` RC1 will not have in built support for Revocation Check feature, see [Key Management - Rescinding Signatures (CRL)](https://github.com/notaryproject/notaryproject/issues/72) for details. When this feature is subsequently implemented, the `strict` verification level will **enforce** this validation, and will fail signatures which would previously pass signature verification when revocation checks were not supported. This is considered a **breaking change**, but is the appropriate behavior for a `strict` verification level. | |||
| - **NOTE** : `notation` RC2 will not have in built support for Revocation Check feature, see [Key Management - Rescinding Signatures (CRL)](https://github.com/notaryproject/notaryproject/issues/72) for details. When this feature is subsequently implemented, the `strict` verification level will **enforce** this validation, and will fail signatures which would previously pass signature verification when revocation checks were not supported. This is considered a **breaking change**, but is the appropriate behavior for a `strict` verification level. | |||
There was a problem hiding this comment.
How about not mentioning the release version, I am afraid we will update it again in the future.
There was a problem hiding this comment.
Good point, I've removed this section from here as this is notation limitation(implementation missing) not notary v2 spec limitation.
There are two ways in which we can surface this limitations to users
- Create PR in notation's README.md to call out its limitation.
- Call them as part of release notes
I think we should should do both(which should be done separately as release activity.
There was a problem hiding this comment.
I agree with you to remove it, since it is more about implementation progress, not specification itself. I did notice that there is a release for this repo https://github.com/notaryproject/notaryproject/releases/tag/v1.0.0-rc.1, which is also called rc.1. Will this cause confusion that the spec rc.1 matched the notation rc.1?
I also agree with you that we should put the limitations in both Readme.md and release notes. In the future, we should also link the release note or create a different format in notaryproject website. Currently we don't have release blogs yet. see example https://oras.land/blog/oras-0.14-and-future/
There was a problem hiding this comment.
I did notice that there is a release for this repo https://github.com/notaryproject/notaryproject/releases/tag/v1.0.0-rc.1, which is also called rc.1. Will this cause confusion that the spec rc.1 matched the notation rc.1?
IMO, that should not be an issue. Spec version and implementation versions can (and will) diverge, its implementations responsibility to call out which spec version it supports.
There was a problem hiding this comment.
Tracking it in #233
|
Can we split the PR into smaller PRs although this PR overall LGTM? Basically, one PR one purpose. Otherwise, the combine PR may take longer time to review and may be stale in the end. |
Signed-off-by: Pritesh Bandi <pritesb@amazon.com>
Yes there are multiple changes but at high level there are only two changes
Although I can split above two changes into separate PRs but that wouldn't help much |
Change log
5.Removed verification extensibility TODO and replaced it with link to plugin spec link