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.

Sign up for GitHub

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

libimage: fix reference filters #1503

Merged
merged 1 commit into from
Jun 14, 2023
Merged

libimage: fix reference filters #1503

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 10 additions & 2 deletions libimage/filters.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -178,7 +178,7 @@ func (r *Runtime) compileImageFilters(ctx context.Context, options *ListImagesOp
filter = filterManifest(ctx, manifest)

case "reference":
filter = filterReferences(value)
filter = filterReferences(r, value)

case "until":
until, err := r.until(value)
Expand Down Expand Up @@ -268,8 +268,15 @@ func filterManifest(ctx context.Context, value bool) filterFunc {
}

// filterReferences creates a reference filter for matching the specified value.
func filterReferences(value string) filterFunc {
func filterReferences(r *Runtime, value string) filterFunc {
lookedUp, _, _ := r.LookupImage(value, nil)
return func(img *Image) (bool, error) {
if lookedUp != nil {
if lookedUp.ID() == img.ID() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems imprecise to me.

The code below seems fairly clear that fedora:38 is intended to match example.com/any/namespaces/fedora:38; and even that wildcards work, so fe*ra:38 is intended to match.

Is that correct?

If so, fe*ra@sha256:$digest should also match — but LookupImage can (I hope?) never resolve fe*ra.

IOW, if the underlying problem is that img.NamesReferences() does not contain digests, I think that needs to be solved directly here, not by relying on the LookupImage crutch (and on the lookupImageInDigestsAndRepoTags code path for matching short names) — maybe by combining img.NamesReference() with img.RepoDigests() when building candidates.

Now, RepoDigests is imprecise and relying on it would also introduce a weak variant of #1248 (where an image that exists on registry as repo1@digest1 and repo2@digest2 can be referenced using repo1@digest2, although that exists on no registry — but it’s a weaker variant because otherRepo@digest1 does not match). Ideally we should fix RepoDigests, but that’s a whole other set of PRs again.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even more extreme, wildcards inside the digest? fedora@sha*:a?b*c ?

return true, nil
}
}

vrothberg marked this conversation as resolved.
Show resolved Hide resolved
refs, err := img.NamesReferences()
if err != nil {
return false, err
Expand Down Expand Up @@ -306,6 +313,7 @@ func filterReferences(value string) filterFunc {
}
}
}

return false, nil
}
}
Expand Down
1 change: 1 addition & 0 deletions libimage/filters_test.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -62,6 +62,7 @@ func TestFilterReference(t *testing.T) {
{"quay.io/libpod/*", 2},
{"busybox", 1},
{"alpine", 1},
{"alpine@" + alpine.Digest().String(), 1},
} {
listOptions := &ListImagesOptions{
Filters: []string{"reference=" + test.filter},
Expand Down