Will help allow ostree pull images from internal registries Helps https://github.com/ostreedev/ostree-rs-ext/issues/121

Also change authfile type from String to PathBuf

We need this for a few reasons:

• It has the layer ordering, which we are currently ignoring but will probably be important for correctness later
• It is the only thing that has extensible metadata that will survive round trips through docker schema 2

This API exposes the "GetLayerInfosForCopy" API in containers/image, which can be used to create a mapping between blob and diff IDs, allowing pulling via diffID.

Signed-off-by: RishabhSaini [email protected]

Motivated by https://github.com/ostreedev/ostree-rs-ext/pull/413 which is in turn an adaption of code that lives in rpm-ostree today from https://github.com/coreos/rpm-ostree/commit/d661e8f974f8d2550a865c2866476160e333ec72 which aims to support privilege separation.

This doesn't lower privilege separation into this project (yet), just aids in passing data across boundaries.

While we should offer a way to get the raw bytes, I think we should depend on https://docs.rs/oci-spec/latest/oci_spec/ by default, e.g. get_manifest() -> oci_spec::image::ImageManifest.

This is just exposing skopeo's --no-creds. I would like to flip the ostree-as-system case to use this by default, because I don't think the host OS upgrades should read from /root by default.

Instead, I plan to change the ostree stack to support something like /etc/ostree/container-auth.json so it can be distinct from what the "root user"'s config is.

Further, the config needs to be in /etc because /root is on /var on ostree systems, and we want to support transactional updates to the pull config.

(Anyways, that's all mostly ostree stuff, this is just exposing the option)

This will allow higher level tooling to inject their own sandboxing.

I would like to add opinionated usage of e.g. systemd-run but this is a useful start.

https://github.com/containers/skopeo/pull/1495 landed, but we need to bind it.

This actually introduces a new problem, which is detecting at runtime support for API methods based on semver.

We need to support the equivalent of skopeo inspect --tls-verify=false. This may require an skopeo experimental-image-proxy API addition too - like properties on OpenImage?

Confusingly, today running skopeo some-unknown-command just outputs usage information to stdout, and exits successfully.

I'll probably fix that to exit with an error, but either way we need to handle the case where skopeo exits before we get a reply from the socketpair.

The latest release fails to pull images from authenticated repositories. This only happens on rpm-ostree: Version: '2022.18' Which pulls containers-image-proxy-rs latest release.

rpm-ostree rebase --experimental ostree-unverified-registry:ghcr.io/user/private-repo:latest

Pulling manifest: ostree-unverified-image:docker://ghcr.io/user/private-repo:latest
error: Conflicting authentication options

This relates to https://github.com/containers/containers-image-proxy-rs/pull/31 - basically it would make way more sense for us to expose methods on an opened image.

This would also help fix https://github.com/coreos/rpm-ostree/issues/4213 because then we could impl Drop on it so that the image is automatically closed.

I think a good pattern is to keep an open (draft) pull request that should fail CI, and verify that it actually does.

It's surprisingly easily to e.g. have CI not actually test the code. In this case we have our "reverse dependency testing" which patches the crate to use the local code, and that could easily not work.