Add layout package for writing and loading signatures from disk #1040
Conversation
Signed-off-by: Priya Wadhwa <priyawadhwa@google.com>
priyawadhwa
force-pushed
the
layout
branch
4 times, most recently
from
7821569
to
b3ee0ef
Compare
Signed-off-by: Priya Wadhwa <priyawadhwa@google.com>
pkg/oci/layout/image.go
Outdated
|
|
||
| // SignedImage provides access to a remote image reference, and its signatures. | ||
| func SignedImage(path string) (oci.SignedImage, error) { | ||
| p, err := layout.FromPath(imagePath(path)) |
There was a problem hiding this comment.
Is this ~always an index? If so, I'm wondering if we should only expose SignedIndex 🤔 (or at least start there instead, and add "sugar" later)
There was a problem hiding this comment.
The index is the entrypoint into this layout -- you could interpret the entire layout as a single index and push that to a registry, but I think it's more interesting to just use this index data structure as a list of what's contained within the directory. You can have a bunch of cosign-isms around annotations on the top-level index.json index that are meaningful to cosign without them leaking from this implementation.
There was a problem hiding this comment.
It might be interesting to have an idea of a "snapshot" of a SignedImage, that is implemented as an index that points to every piece of relevant metadata?
Signed-off-by: Priya Wadhwa <priyawadhwa@google.com>
Signed-off-by: Priya Wadhwa <priyawadhwa@google.com>
Signed-off-by: Priya Wadhwa <priyawadhwa@google.com>
Signed-off-by: Priya Wadhwa <priyawadhwa@google.com>
priyawadhwa
changed the title
Signed-off-by: Priya Wadhwa <priyawadhwa@google.com>
|
Hey @jonjohnsonjr & @mattmoor, I refactored a bit to store everything in a single index as recommended. The sample {
"schemaVersion": 2,
"manifests": [
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 528,
"digest": "sha256:69704ef328d05a9f806b6b8502915e6a0a4faa4d72018dc42343f511490daf8a",
"annotations": {
"dev.cosignproject.cosign/image": "true"
}
},
{
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"size": 501,
"digest": "sha256:4c4dc104ee4357651d17a2e4f8faf2d64457acc7fff2d306312abf69c7bbe4c9",
"annotations": {
"dev.cosignproject.cosign/sigs": "true"
}
}
]
} |
| imageAnnotation = "dev.cosignproject.cosign/image" | ||
| sigsAnnotation = "dev.cosignproject.cosign/sigs" |
There was a problem hiding this comment.
@dlorenc What's standard here? should this be dev.sigstore.cosign? Are we documenting these anywhere?
There was a problem hiding this comment.
It probably should be dev.sigstore but I apparently never switched them over from the first version, so dev.cosignproject is currently everywhere. We should open a separate issue to track/document/change all of these.
| sigs, err := si.Signatures() | ||
| if err != nil { | ||
| return errors.Wrap(err, "getting signatures") | ||
| } | ||
| if err := write(path, signaturesPath, sigs); err != nil { | ||
| return errors.Wrap(err, "writing signatures") | ||
| if err := appendImage(layoutPath, sigs, sigsAnnotation); err != nil { |
There was a problem hiding this comment.
If the resulting index were pushed, how would it run?
There was a problem hiding this comment.
Generally clients take the first entry that matches their criteria (platform).
This might be a reasonable knob to expose when pushing to a registry? By default, just push all the entries in index.json, but optionally include that index.json as a top-level index for everything related to the artifact. I don't know how this is intended to be used.
There was a problem hiding this comment.
for cosign load I was planning on pushing everything in index.json for now and not including the index.json itself so this effectively is the same as running cosign copy -- i think it would be cool to optionally include pushing index.json as a feature for later (although running into some errors with it atm that would need to be addressed)
…gnedImage Signed-off-by: Priya Wadhwa <priyawadhwa@google.com>
Added a
layoutpackage topkg/ociwhich should make it easy to store images & associated signatures to disk! This is the first part of implementing #1015TODOs:
sigLayerimplementation into a separate package since it's used byremoteas wellI'm still not sure if I implemented this the correct way, cc'ing @jonjohnsonjr and @mattmoor in case I'm totally on the wrong track 😅