-
Notifications
You must be signed in to change notification settings - Fork 13
Adding proposal D, "no changes" #13
Adding proposal D, "no changes" #13
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this proposal! An option that relies on conventions within the existing specs is worth considering in my opinion. 👍
docs/proposals/d-no-change.md
Outdated
"variant": "v7" | ||
}, | ||
"annotations": { | ||
"vnd.oci.artifact.sig.data": "<base64-encoded-artifact>" // embedding small artifacts |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup. Though in this case the artifact is different from the content the descriptor points to. I.e. if all the signatures are small enough, a multi-platform index could be updated with only annotations, reducing the risk of runtime issues picking the wrong descriptor.
docs/proposals/d-no-change.md
Outdated
"platform": { | ||
"architecture": "arm64", | ||
"os": "linux" | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a concern with this that a runtime might incorrectly pull this SBOM and interpret it as an image? It'd be looking for mediaType == "image" && platform == $myplatform
, which this satisfies.
I guess that's what language introduced in opencontainers/image-spec#880 is meant to guard against.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's certainly a concern of that. Also if we have a reference to an index, we could send up with an index pointing to an index, which may not be traversed by runtimes. Potentially we could use annotations rather than the platform section to associate one descriptor to another.
docs/proposals/d-no-change.md
Outdated
"os": "linux" | ||
}, | ||
"annotations": { | ||
"vnd.oci.artifact": "true", // this descriptor points to an artifact |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Would it be enough to say that if a artifact.type
is set, that it's an artifact? That would let us remove one more moving part in this proposal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My thought on this one is we only depend on the top level artifact = true field, and everything else is an optional field that can be used by clients to filter their future requests.
I happy to see this roll in. Would you be willing to rework this into a new format once we come up a template like we discussed on the call yesterday? @sudo-bmitch |
@jdolitsky Absolutely. Just wanted to get this started while it was fresh in my head. |
See #14 for proposal template PR |
@sudo-bmitch please see #18 - can you re-format this, or open another PR? |
Signed-off-by: Brandon Mitchell <[email protected]>
32f9697
to
0d16925
Compare
Signed-off-by: Brandon Mitchell <[email protected]>
a8c4557
to
f818d82
Compare
Signed-off-by: Brandon Mitchell [email protected]
This is proposal D from our discussions. It looks at how reference types could be implemented without changes to the current OCI specs, similar to the current OCI Artifact definition. I'm assuming this won't satisfy everyone's needs, but it gives us a baseline to compare other proposals, and also provides a fallback option for how to work with registries that don't support any APIs we add.
Fixes #18