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

minor suggestion on tag name of signature index #8

Closed
cppforlife opened this issue Feb 9, 2021 · 6 comments
Closed

minor suggestion on tag name of signature index #8

cppforlife opened this issue Feb 9, 2021 · 6 comments

Comments

@cppforlife
Copy link

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 to sha256-... lookup tag so that it's cosign-sha256-... mostly to have some kind of namespacing between tools using similar approach for lookups.

@dlorenc
Copy link
Member

dlorenc commented Feb 10, 2021

SGTM! What do you think about using a suffix? sha256-dfasfd.cosign ?

@dlorenc
Copy link
Member

dlorenc commented Feb 10, 2021

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.

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!

@jonjohnsonjr
Copy link
Contributor

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:

image

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.

@dlorenc
Copy link
Member

dlorenc commented Feb 11, 2021

I'm so excited for our glorious future of registry polyfills.

@cppforlife
Copy link
Author

SGTM! What do you think about using a suffix? sha256-dfasfd.cosign ?

suffix also works. just wanted a good scheme for using sha256-xxx pattern collectively.

@dlorenc
Copy link
Member

dlorenc commented Feb 15, 2021

OK, added the ".cosign" suffix!

@dlorenc dlorenc closed this as completed Feb 15, 2021
tommyd450 pushed a commit to tommyd450/cosign that referenced this issue Oct 26, 2023
* Changes needed for rhtap support

* change-to-how-tekton-is-handeled
amartin120 added a commit to amartin120/cosign that referenced this issue Mar 15, 2024
dmitris added a commit to dmitris/cosign that referenced this issue Jul 10, 2024
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>
dmitris added a commit to dmitris/cosign that referenced this issue Jul 10, 2024
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>
dmitris added a commit to dmitris/cosign that referenced this issue Jul 10, 2024
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>
dmitris added a commit to dmitris/cosign that referenced this issue Jul 11, 2024
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants