Baseline CLI reference for subsequent PRs on changes #171
Conversation
Signed-off-by: Steve Lasker <[email protected]>
|
| push Push signature to remote | ||
| pull Pull signatures from remote | ||
| list, ls List signatures from remote | ||
| certificate, cert Manage certificates used for verification |
There was a problem hiding this comment.
Given that we decided to manage certificates using the trust policy defnition, should we drop
certificate and key
There was a problem hiding this comment.
Also considering this usecase for local file with passpharse should we possibly have --passpharse as an option for sign. Are we planning to include sub command options for the CLI here?
notaryproject/roadmap#46
There was a problem hiding this comment.
We need to think through the initial experience and production experiences here.
What is the user experience to get started?
What is the user experience to add remote signed keys?
What is the user experience to add certs for verification?
Today, this can be accomplished with some straight-forward commands.
What will this experience look like in RC1?
There was a problem hiding this comment.
notation cert add is an alpha 1 command created before trust store and trust policy spec was finalized, and is not compatible with the spec. RC1 implements spec which uses trust store and trust policy instead of a global certificate list in config.json. This cert add command needs rename/changes along with possibly new commands to manage trust policy, which are currently not in scope for for RC1 release. RC1 is prioritizing core functionality, sign & verify commands, over usability of other features. We may update some other commands like key add or plugin list as part of ongoing work, but these are not blockers for RC1 release. Users can accomplish these scenarios by manually editing trust store, trust policy, config.json/signingkeys.json . We plan to add/update commands post RC1 and before GA release.
See examples here for how this needs to be configured for RC1 - trust store , trust policy.
|
Why? Users should be able to validate their environment is set up properly before they use it for their production workloads. |
Signed-off-by: Steve Lasker <[email protected]>
Signed-off-by: Steve Lasker <[email protected]>
|
Based on the Notary call today, I've flipped to ready for review/merge. |
SteveLasker
dismissed
sajayantony’s stale review
merging as is, with changes to come as separate PRs
SteveLasker
changed the title
| ## Table of Contents | ||
| - [notation](#notation) | ||
| - [sign](#sign): Signs artifacts | ||
| - [verify](#verify): Verifies OCI Artifacts |
There was a problem hiding this comment.
nit: Sign command just says "Sign artifacts", and verifies says "Verifies OCI artifacts". Is that on purpose.
There was a problem hiding this comment.
i just copy pasted what the cli currently has. So, yeah, bug that should be changed.
This PR is what exists to be modified.
Reminder, this is the baseline of the current experience. We should merge, as-is, then make incremental PRs for each command, or header text. |
SteveLasker
changed the title
specs/notation-cli.md
Outdated
| # Notation CLI | ||
|
|
||
| The following spec outlines the notation CLI. | ||
| The CLI commands are what's currently available in [notation v0.7.1-alpha.1](https://github.com/notaryproject/notation/releases/tag/v0.7.1-alpha.1) |
There was a problem hiding this comment.
| The CLI commands are what's currently available in [notation v0.7.1-alpha.1](https://github.com/notaryproject/notation/releases/tag/v0.7.1-alpha.1) | |
| The CLI commands are what's currently available in [notation v0.7.1-alpha.1](https://github.com/notaryproject/notation/releases/tag/v0.7.1-alpha.1). The CLI experience in alpha.1 does not represent the final user experience, and CLI commands may have breaking changes before RC release as the CLI experience is refined. |
Signed-off-by: Steve Lasker <[email protected]>
Closes #88
Signed-off-by: Steve Lasker [email protected]