Fetching manifest from ECR fails due to missing Docker-Content-Digest header

[venushka]

NullPointerException when fetching manifest from ECR

I am attempting to fetch an Manifest for a container image, and it is throwing a NullPointerException. I've reproduced this with a public ECR image here.

    Registry registry = Registry.builder().build();
    ContainerRef containerRef = ContainerRef.parse("public.ecr.aws/docker/library/alpine:latest");

    Index index = registry.getIndex(containerRef);
    String digest = index.getManifests().get(0).getDigest();
    Manifest manifest = registry.getManifest(containerRef.withDigest(digest));

fails with

Exception in thread "main" java.lang.NullPointerException
	at java.base/java.util.Objects.requireNonNull(Objects.java:209)
	at land.oras.ManifestDescriptor.of(ManifestDescriptor.java:202)
	at land.oras.ManifestDescriptor.of(ManifestDescriptor.java:191)
	at land.oras.Registry.getManifest(Registry.java:564)
	at test.EcrManifestTest.main(EcrManifestTest.java:33)

Debugging through the code I found that the getDescriptor call inside getManifest populates the digest based on the Docker-Content-Digest header value, which ECR doesn't seem to return. This results in the ManifestDescriptor.of call in getManifest to fail with the digest not null assertion at the beginning. Seems like the only headers its returning are,

headers = {HashMap@3651}  size = 4
 "date" -> "Fri, 06 Feb 2026 14:59:39 GMT"
 "docker-distribution-api-version" -> "registry/2.0"
 "content-type" -> "application/vnd.oci.image.index.v1+json"
 ":status" -> "200"

In this particular case, I already know the digest as well, as I've passed it in as part of the ContainerRef which probably can be set using that, but then it would be problematic if this is called with a container ref without a digest. Maybe if digest doesn't get returned, it could do a probe request to get the digest if the container ref doesn't have the digest in it?

[jonesbusy]

Probably similar fix #516 is needed.

Thanks for the details and reproducer

[jonesbusy]

While doing more test with public.ecr.aws I found other difference with all registries I tested

Typically a HEAD request to blobs always return a 401 event with a valid token (This works for manifest)

For example

http -v HEAD "https://public.ecr.aws/v2/docker/library/alpine/blobs/sha256:589002ba0eaed121a1dbf42f6648f29e5be55d5c8a6ee0f8eaa0285cc21ac153" "Authorization: Bearer $AUTH_TOKEN"

While

http -v GET "https://public.ecr.aws/v2/docker/library/alpine/blobs/sha256:589002ba0eaed121a1dbf42f6648f29e5be55d5c8a6ee0f8eaa0285cc21ac153" "Authorization: Bearer $AUTH_TOKEN"

We get a 307 which redirect to a cloudfront URL which is correctly followed by the HTTP client

This is definitely different from other registries

I'm honnestly a bit confused with https://github.com/opencontainers/distribution-spec/blob/main/spec.md#pulling-blobs

A HEAD request to an existing blob or manifest URL MUST return 200 OK. A successful response SHOULD contain the digest of the uploaded blob in the header Docker-Content-Digest. A successful response SHOULD contain the size in bytes of the uploaded blob in the header Content-Length.

[jonesbusy]

Should be fix by #526

I will try to perform more test before performing a new release