fix: avoid content storage pollution by limiting the fallback on ref resolution#13017
Conversation
25abd40 to
d650aa4
Compare
…esolution Signed-off-by: Joseph Zhang <[email protected]>
github-project-automation
Bot
moved this from Review In Progress
to Done
in Pull Request Review
|
/cherry-pick release/2.2 |
|
@thaJeztah: new pull request created: #13620 DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/cherry-pick release/2.1 |
|
/cherry-pick release/2.0 |
|
@thaJeztah: new pull request created: #13621 DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
@thaJeztah: new pull request created: #13622 DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
thaJeztah
added
cherry-picked/2.0.x
6 participants
/kind bug
What
Fixes: #13007 by limiting the fallback to
/blobsendpoint onresolve.Resolve. It could permanently corrupt an image in local content store due to incorrectcontent-typereturned.Alternatives considered
Remove the
/blobs/fallback entirelyThe
/blobs/fallback was introduced to support non-standard or legacy registries that serve manifest content only through the blob endpoint. Removing it entirely would be the cleanest fix, but could silently break users relying on this behavior without any clear migration path. Since there is no registry conformance test enforcing the/manifests/endpoint, some private/custom registries may depend on it. Rejected to avoid a potentially breaking change.Validate the
Content-Typereturned by/blobs/against known manifest media typesAfter falling back to
/blobs/, check whether the returnedContent-Typeis a recognized manifest or index media type (usingimages.IsManifestType/images.IsIndexType). If not, skip the result and continue.This approach catches the symptom (wrong media type) rather than the cause (wrong error triggering the fallback). It also makes a hidden assumption that
Resolve()is only ever used to resolve manifests — butResolve()is a general-purpose descriptor resolver and/blobs/is a legitimate path for non-manifest content in some workflows. Rejected as too narrow and fragile.