artifacts-spec
artifacts-spec copied to clipboard
oras-project
Test Caes for Interop Scenarios and Comparison Grid
A list of scenarios to consider for various fallback options, supporting OCI 1.1 based registries.
SVG's on this are rendering strange with Firefox on Linux
Ugh, the font, positioning conpat fun. I’ll convert to pngs
Pulling this discussion out of the line item comments:
The comments around "product pitch" are a little distracting from the conversation. Can you elaborate what "product" this is pitching? This is a proposal of how ORAS Artifacts CNCF project may interop with downlevel registries.
Scenarios to me should cover a problem that a user is facing. And as a user, none of my problems today involve ORAS Artifacts. My goals are to push signatures, SBOMs, helm charts, etc, a registry without breaking my other workflows. And some of those registries may be managed by other groups, possibly by a 3rd party SaaS, where I have no ability to change the registry implementation. So I'm bothered to see the notary project's issue #112 moved from an implementation neutral place to solving it here where the answers are all biased to start from "ORAS Artifacts are the solution". It really feels like we're poisoning the well on this, especially since it presupposes one of many possible outcomes from the OCI Reference Types Working Group.
Everything you've outlined is why we're discussing how we enable fallback in ORAS so the user doesn't have to think about the details. We want to enable an abstract way to get the benefits of a registry that has rich support for references, with interop of registries that don't. A user should be able to move between those with some level of fidelity. The graph the ability for each to enable the scenarios.
Notary v2 has a dependency on ORAS and ORAS Artifacts to manage registry interactions. How is this any different than cosign taking a dependency on sigstore or crane? ORAS is vendor-neutral and the underpinnings registry interactions for Notary. Why is this a problem?
As the OCI Reference working group proceeds, we can consider the outcome. Months ago, it was agreed we'd proceed with ORAS in parallel so Notary V2 can make progress. These are parallel efforts, where ORAS Artifacts is an implementation that's taking feedback, based on use.
How is this any different than cosign taking a dependency on sigstore or crane?
Just going to clarify this point - cosign depends only on the existing, 1.0 version of the OCI Image and Distribution specifications, with no extensions.
Notary v2 has a dependency on ORAS and ORAS Artifacts to manage registry interactions. How is this any different than cosign taking a dependency on sigstore or crane? ORAS is vendor-neutral and the underpinnings registry interactions for Notary. Why is this a problem?
My desire in looking at fall back solutions is how to handle registries where ORAS Artifacts today is not an option. So the productive path forward to me is to start from the view that there's a registry without any of this API support, assume that we don't have any of the possible solutions that could result from the Reference Type WG, and evaluate possible solutions to the problem. Then once we decide what makes the most sense, if you want to implement that in ORAS Artifacts, great. But starting the question where you already have the answer you want to push is concerning to me, both as a user, and as someone that would like to interoperate with other code that won't be adding an ORAS dependency.
Cosign is a good example, because I don't recall them pushing that I need to implement go-containerregistry to support their signing spec, it's only to compile their specific implementation. And since they stuck to fairly standard OCI primitives, I've been able to write my own tooling that pulls and copies their signatures with the image across registries/repositories, none of which required that I look at crane code to understand their spec.
cosign depends only on the existing, 1.0 version of the OCI Image and Distribution specifications, with no extensions.
Cosign uses "hacks", your words. The proposal here are ways to avoid those hacks and bring the APIs forward to support the scenarios outlined.
The comparison here is cosign depends on new sigstore services and uses crane for registry operations. Notary depends on oras for registry operations, but no external services. There are enhancements registries can choose to implement, to bring their platforms forward. This proposal is how to account for 1.1 registries, so we have interop. We're simply calling out the details so we have a full comparison.
My desire in looking at fall back solutions is how to handle registries where ORAS Artifacts today is not an option.
ORAS Artifacts is a spec for how to store reference types, with all the scenarios captured here. ORAS and ORAS-go are implementations of that spec. By capturing the fallback scenarios in the ORAS Artifact spec, different implementations can follow the same pattern. This way, you can implement the pattern in other registry clients.
The comparison here is cosign depends on new sigstore services and uses crane for registry operations.
Just correcting this point, not attempting to weigh on on the rest of this - cosign does not depend on any sigstore services. It can use some optionally, but basic container signing and verification depends only on the existing, 1.0 version of the OCI Image and Distribution specifications, with no extensions. Cosign does not depend on crane.
Hey folks - Does it make sense to schedule a time to talk through these scenarios? I've taken a read myself and have several questions and I personally would benefit from a walk through from Steve on the intent and goals he had in mind so that I can correctly frame the context while pondering. I seldom see documents/proposals of this length and on topics that I don't have any prior art as a frame of reference hard to parse without at least having a Q&A with the author. Just a suggestion and I'm happy to do the leg work getting a time setup.
The goals of the call would be to walk through the doc with Steve and get the context and intent. Then offer any feedback on how the document to be better structured so that the information is correctly conveyed. From there we can break back out into the comments.
I'm going to be frank here - that kind of meeting sounds great, but should that just happen in the Reference Types WG? Why have a separate effort and meeting here? As far as I can tell it's the same topic and mostly the same people.
+1 to a meeting, and possibly even bringing this up in the context of the OCI Reference Types WG. If we do that, I'd love to get alignment between us all on this topic first, then bring it to that wider group as a united front, to get another round of feedback from them. Otherwise we risk distracting that goal and audience even more with this topic.
Okay. I will work on getting a meeting scheduled. There's no reason why we can't continue discussing these scenarios in the context of the ORAS project.
Just correcting this point, not attempting to weigh on on the rest of this - cosign does not depend on any sigstore services. It can use some optionally, but basic container signing and verification depends only on the existing, 1.0 version of the OCI Image and Distribution specifications, with no extensions. Cosign does not depend on crane.
From sigstore/cosign docs:
cosignuses go-containerregistry for registry interactions, which has generally excellent compatibility, but some registries may have quirks.
Not sure the point you're trying to make here. Crane is a CLI tool, go-containerregistry is a library.
cosign uses the go-containerregistry library to interact with OCI registries, like many other things: https://github.com/justincormack/sign-index/blob/main/pkg/signing/signing.go#L15
Notary v2 has a dependency on ORAS and ORAS Artifacts to manage registry interactions. How is this any different than cosign taking a dependency on sigstore or crane?
This is a category error. Using a different client library is not the same as forking the protocol.
cosign uses go-container registry (crane as the cli) for working with a registry. notary uses oras-go as the library to interact with a registry. These are the analogies, so lets just acknowledge there are similar concepts here.
@jonjohnsonjr what fork of a protocol are you referring to?
cosign uses go-container registry (crane as the cli) for working with a registry.
Still not sure what this part means. cosign does not use crane, cosign uses the go-containerregistry library. I don't see the importance of this either way though, so I think I might be missing something.
Still not sure what this part means. cosign does not use crane, cosign uses the go-containerregistry library. I don't see the importance of this either way though, so I think I might be missing something.
The question above was, (paraphrased): "why does notation depend on oras-go".
My answer was (paraphrased): "because we don't think notary shouldn't have to deal with registry details. We have a library for working with registries that understand how to support references, and we believe this is universally applicable. Not just for signatures.".
This is no different than cosign depends on go-containerregistry for registry operations. I used crane as the representation for go-containerregistry.
There's value in the factoring. cosign surfaces the apis slightly differently, but conceptually, its the same factoring where you're leveraging a registry library to do the details.