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

ux: distinguish public key vs private key in CLI #74

Closed
ahmetb opened this issue Mar 11, 2021 · 9 comments
Closed

ux: distinguish public key vs private key in CLI #74

ahmetb opened this issue Mar 11, 2021 · 9 comments
Labels
enhancement New feature or request wontfix This will not be worked on

Comments

@ahmetb
Copy link
Contributor

ahmetb commented Mar 11, 2021

Right now -key flag is used in both meanings "public key" and "private key".

It might be wise to distinguish these as -key and -pub earlier than later. Please vote 👍🏼 👎🏼 .

USAGE
  cosign verify -key <key> <image uri>

FLAGS
  -a ...              extra key=value pairs to sign
  -check-claims true  whether to check the claims found
  -key ...            path to the public key
  -kms ...            verify via a public key stored in a KMS
USAGE
  cosign sign -key <key> [-payload <path>] [-a key=value] [-upload=true|false] [-force-tlog=true|false] <image uri>

FLAGS
  -a ...             extra key=value pairs to sign
  -force-tlog false  whether to upload to the tlog even when the image is private
  -key ...           path to the private key
  -kms ...           sign via a private key stored in a KMS
  -payload ...       path to a payload file to use rather than generating one.
  -upload true       whether to upload the signature
@FalcoSuessgott
Copy link

Hi @ahmetb I would like to provide a PR for this one if u dont mind:)

What do u think about switching to cobra for the cli arg parsing?

@ahmetb
Copy link
Contributor Author

ahmetb commented Mar 11, 2021

I was planning to implement this to get used to the repo, but I’m also noticing a need for using cobra more broadly in other issues as well.

@FalcoSuessgott
Copy link

Alright I will keep looking then for a chance to contribute

@dlorenc
Copy link
Member

dlorenc commented Mar 12, 2021

+1 to someone doing this one! I don't love cobra but could be convinced to switch as long as we don't also bring in viper.

@lukehinds lukehinds added the enhancement New feature or request label Mar 15, 2021
@dlorenc dlorenc mentioned this issue Mar 20, 2021
9 tasks
@dlorenc
Copy link
Member

dlorenc commented Mar 27, 2021

@FalcoSuessgott are you still interested in trying this?

@FalcoSuessgott
Copy link

@dlorenc implementing that feature or migrating to cobra?

@ahmetb
Copy link
Contributor Author

ahmetb commented Mar 30, 2021

FWIW I came to terms calling both pub/priv "-key" over time. So I am not sure if this is worth fixing. -key is more friendly than -pub/-priv?

@znewman01
Copy link
Contributor

FWIW I came to terms calling both pub/priv "-key" over time. So I am not sure if this is worth fixing. -key is more friendly than -pub/-priv?

+1, it's usually unambiguous from the context (e.g. cosign sign --key wants the signing==private key, cosign verify --key wants the verification==public key). Plus it'll fail if you give it the wrong one.

Closing as WONTFIX

@znewman01
Copy link
Contributor

Also we have migrated to Cobra in the meantime.

@znewman01 znewman01 added the wontfix This will not be worked on label Nov 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

5 participants