Jib should report the image digest used for the base image to simplify configuring a fixed digest, and also for traceability.
Hi! Can I take this up?
Sure, thanks!
Presumably we could just read the Docker-Content-Digest HTTP header in ManifestPuller and print the SHA there.
Alternatively we could compute the SHA on the fly inside ManifestPuller (with SHA256 for now).
However, @jonjohnsonjr sent us some links and said to proceed with caution with the header approach, as registries have implemented this so differently. Generally it's questionable to trust the header value.
sha256: in the header value)So @chanseokoh I shall work on getting the manifest from the registry first. This should resolve #2034 as well.
@chanseokoh There is one problem with computing the digest from the response directly. Manifest has signatures. We compute the digest from the manifest without the signatures. And you had suggested to compute the digest directly from the inputStream.
Only schema 1 images have signatures, which jib doesn't support (I believe).
@jonjohnsonjr Jib doesn't support pushing schema 1 images, but it supports pulling schema 1 base images.
@tejaskasetty I think we can ignore schema 1 manifests. They will be gone sooner or later. We are checking if the schema is 1 or 2 in ManifestPuller (I believe), so perhaps we should report the digest only when it is 2. And the digest of the schema 2 manifests will exactly be the SHA256 checksum of the blob content.
Fixed by #2063.
@dev-gaur We've released 1.7.0 with @tejaskasetty's fix!
Most helpful comment
@jonjohnsonjr Jib doesn't support pushing schema 1 images, but it supports pulling schema 1 base images.
@tejaskasetty I think we can ignore schema 1 manifests. They will be gone sooner or later. We are checking if the schema is 1 or 2 in
ManifestPuller(I believe), so perhaps we should report the digest only when it is 2. And the digest of the schema 2 manifests will exactly be the SHA256 checksum of the blob content.