-
Notifications
You must be signed in to change notification settings - Fork 547
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
minor suggestion on tag name of signature index #8
Comments
SGTM! What do you think about using a suffix? sha256-dfasfd.cosign ? |
And on this question - I don't really have a great answer yet. I need to sign containers and can't really wait for nv2. I'd be happy to use nv2 or something else if handled everything this does. So, I'd like to continue to support this until/if something larger/more standardized gets adopted. I don't want to increase the size/scope of this project too much, but if there are small things that will allow others to adopt it I'm all for that! |
We've discussed a couple other approaches that might help avoid collisions, e.g. having a separate child or sibling repository that contains only signatures, or stacking all signatures onto a single tagged artifact: Of course, both of these approaches make things slightly more complicated, but at least they don't pollute the repository with tons of tag noise... either way, I think these are stopgaps until we have a first-class mechanism for this kind of thing, at which point these can become a fallback for registries that don't support it. |
I'm so excited for our glorious future of registry polyfills. |
suffix also works. just wanted a good scheme for using sha256-xxx pattern collectively. |
OK, added the ".cosign" suffix! |
* Changes needed for rhtap support * change-to-how-tekton-is-handeled
Currently ImportKeyPair() in pkg/cosign supports only private keys in PKCS sigstore#8 form. This change extends it to also support PKCS #1 for RSA keys ("RSA PUBLIC KEY") and SEC 1 for EC keys ("EC PRIVATE KEY"). Fix sigstore#3775. Signed-off-by: Dmitry S <dsavints@gmail.com>
Currently ImportKeyPair() in pkg/cosign supports only private keys in PKCS sigstore#8 form. This change extends it to also support PKCS #1 for RSA keys ("RSA PUBLIC KEY") and SEC 1 for EC keys ("EC PRIVATE KEY"). Fix sigstore#3775. Signed-off-by: Dmitry S <dsavints@gmail.com>
Currently ImportKeyPair() in pkg/cosign supports only private keys in PKCS sigstore#8 form. This change extends it to also support PKCS #1 for RSA keys ("RSA PUBLIC KEY") and SEC 1 for EC keys ("EC PRIVATE KEY"). Fix sigstore#3775. Signed-off-by: Dmitry S <dsavints@gmail.com>
Currently ImportKeyPair() in pkg/cosign supports only private keys in PKCS sigstore#8 form. This change extends it to also support PKCS #1 for RSA keys ("RSA PUBLIC KEY") and SEC 1 for EC keys ("EC PRIVATE KEY"). Fix sigstore#3775. Signed-off-by: Dmitry S <dsavints@gmail.com>
while working on https://github.com/vmware-tanzu/imgpkg i've also noodled on the idea of using tags for searching related artifacts (signatures and few other things) since there is no other mechanisms available in registry APIs. i'm glad yall came to a similar conclusion :)
im curious where yall see this project head to (is it a poc)... my team have recently popped into notary OSS WG to see where the community is at with regards to an open standards for signing, so curious about your take on this.
onto minor suggestion:
i think it's worth adding
cosign-
prefix tosha256-...
lookup tag so that it'scosign-sha256-...
mostly to have some kind of namespacing between tools using similar approach for lookups.The text was updated successfully, but these errors were encountered: