Adding proposal D, "no changes" #13
Conversation
sudo-bmitch
requested review from
dmcgowan,
imjasonh,
jdolitsky,
jonjohnsonjr,
justincormack,
lachie83,
michaelb990,
nishakm and
SteveLasker
as code owners
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.
There was a problem hiding this comment.
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.
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.
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.
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.
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]>
sudo-bmitch
force-pushed
the
pr-proposal-no-change
branch
from
32f9697
to
0d16925
Compare
Signed-off-by: Brandon Mitchell <[email protected]>
sudo-bmitch
force-pushed
the
pr-proposal-no-change
branch
from
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