Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow referring images in oci: (and oci-archive: ?) by manifest digest #1828

Open
mtrmac opened this issue Feb 3, 2023 · 8 comments
Open
Labels
kind/feature A request for, or a PR adding, new functionality

Comments

@mtrmac
Copy link
Collaborator

mtrmac commented Feb 3, 2023

See containers/podman#17308 for the previous discussion.

@mtrmac mtrmac added the kind/feature A request for, or a PR adding, new functionality label Feb 3, 2023
@mwopfner
Copy link

mwopfner commented Feb 6, 2023

Currently the oci (and oci-archive) does not allow to refer an image by the manifest digest like docker transport does with the @digest syntax.

oci transport currently supports

Proposal
Add support for digest by using one of (or another)

  • @digest Same as used in docker transport. This would add another constrain on path names and may brake currently used image names. Depends on how widely @ is used in path names currently.
  • :@digest Does not brake current behavior, because the name is currently already split by :
    Must be coordinated with :@index which should be possible, because index is a number >= 0 and a digest is of format algorithm:encoded (see: https://github.com/opencontainers/image-spec/blob/main/descriptor.md#digests)

@mwopfner
Copy link

Is there a currently a plan to include this in a further version? If nobody has time currently may I can implement the feature and open a pull request. Only thing that should be defined is the syntax for the digest.

@mtrmac
Copy link
Collaborator Author

mtrmac commented Sep 21, 2023

It’s tracked here as a reasonable RFE; I’m not aware of anyone actively working on it, and a PR would definitely be welcome.


Yes, the syntax is the first thing which needs to be decided. Note that in the algorithm:encoded syntax linked, it is allowed for algorithm to be composed of digits only… So would the presence of the second : be the differentiator? Or possibly we could use some other prefix, not @ — that might be less ambiguous but probably much less intuitive.

@mwopfner
Copy link

mwopfner commented Sep 22, 2023

My idea was to use a regex to separate between the tag, index and digest form. Something like:

tag: ^:([a-zA-Z0-9_][a-zA-Z0-9-_.]{0,127})$ (based on https://docs.docker.com/engine/reference/commandline/tag/)
index: ^:@([0-9]+)$
digest: ^:@([a-z0-9]+([+._-][a-z0-9]+)*:[a-zA-Z0-9=_-]+)$

The above regex also consider the specific constrains for tag and digest. I'm not sure if the restrictions should be enforced here or if another processing step does this and we only have to distinguish between the different cases.

@mwopfner
Copy link

mwopfner commented Feb 2, 2024

@mtrmac what are your thoughts about using regex to separate between these cases? Is this the right way to go or do you have another suggestion?

@mtrmac
Copy link
Collaborator Author

mtrmac commented Feb 2, 2024

Using a regex matcher, or not, is an implementation choice, secondary to choosing the syntax. *shrug*

The above proposes that foo:@0 is an index reference, but foo:@0:0 is a digest reference, differentiated by the presence of the second :, doesn’t it? Purely in abstract that looks a bit confusing, but in practice the algorithm part is going to be sha256 or something very similar, so this might well be the most practical design.

@mwopfner
Copy link

mwopfner commented Feb 5, 2024

Yes, that is correct foo:@0 would be an index and foo:@0:0 is a digest reference. So the second : (plus some trailing characters) is the main divider.

What is the process to decide which syntax to use or should I just implement it and open a PR?

@mtrmac If I implement this function would a regex solution be accepted or are there other ways to do it which are preferred/used in the library.

@mtrmac
Copy link
Collaborator Author

mtrmac commented Feb 5, 2024

Just open a PR, I think. No committee regularly meeting to present a proposal in triplicate to :)

Intuitively I’m a bit skeptical that using a regex is ideal — regexes are fairly costly, and it seems harder to me to be certain that the decision is unambiguous and has been comprehensively tested (we require *_transport.go to have detailed unit tests).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature A request for, or a PR adding, new functionality
Projects
None yet
Development

No branches or pull requests

2 participants