This repository has been archived by the owner on Nov 7, 2024. It is now read-only.
Add API and CLI to update detached metadata #301
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In the FCOS use case and I'm sure others, we want a flow where we do a build (including a container image) and then once it's ready, we sign it by passing the commit metadata to a separate system. Basically what we want is the ability to update the detached metadata object in an exported container image. Now, I'm regretting the design choice to have the container flow reuse the tar path of having the signature be part of the tar stream instead of part of the container metadata, because it *greatly* complicates things here, particularly in terms of handling chunked images. We want to preserve all metadata and other layers in the image; we just need to add/replace a single entry in the layer that has the ostree metadata. Except, because this ostree layer gets its own special label in the container image metadata, we need to update that label. What would make this a lot easier is if we had write support via skopeo/containers-image-proxy. Because we don't, given an image on a remote registry, right now we pull the whole thing down into a temporary OCI directory, even though we only want to mutate one layer. Closes: ostreedev#295
cgwalters
force-pushed
the
inject-signature
branch
from
d4051c9 to
d4e8e02
Compare
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this pull request
May 24, 2022
cgwalters
added a commit
to cgwalters/coreos-assembler
that referenced
this pull request
May 31, 2022
Right now, I want to test the new ostree code to inject signatures: ostreedev/ostree-rs-ext#301 And I want to do it *before* releasing a new rpm-ostree. Add a new Dockerfile with pulls from our continuous COPR. This is effectively the coreos-assembler dual of coreos/fedora-coreos-config#1710
cgwalters
added a commit
to cgwalters/coreos-assembler
that referenced
this pull request
May 31, 2022
Right now, I want to test the new ostree code to inject signatures: ostreedev/ostree-rs-ext#301 And I want to do it *before* releasing a new rpm-ostree. Add a new Dockerfile with pulls from our continuous COPR. This is effectively the coreos-assembler dual of coreos/fedora-coreos-config#1710
jlebon
pushed a commit
to coreos/coreos-assembler
that referenced
this pull request
May 31, 2022
Right now, I want to test the new ostree code to inject signatures: ostreedev/ostree-rs-ext#301 And I want to do it *before* releasing a new rpm-ostree. Add a new Dockerfile with pulls from our continuous COPR. This is effectively the coreos-assembler dual of coreos/fedora-coreos-config#1710
7 tasks
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the FCOS use case and I'm sure others, we want a flow where
we do a build (including a container image) and then once it's ready,
we sign it by passing the commit metadata to a separate system.
Basically what we want is the ability to update the detached metadata
object in an exported container image.
Now, I'm regretting the design choice to have the container flow
reuse the tar path of having the signature be part of the tar stream
instead of part of the container metadata, because it greatly
complicates things here, particularly in terms of handling chunked
images.
We want to preserve all metadata and other layers in the image;
we just need to add/replace a single entry in the layer that has
the ostree metadata.
Except, because this ostree layer gets its own special label
in the container image metadata, we need to update that label.
What would make this a lot easier is if we had write support
via skopeo/containers-image-proxy. Because we don't, given
an image on a remote registry, right now we pull the whole thing
down into a temporary OCI directory, even though we only want to
mutate one layer.
Closes: #295