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

Ignore non matching digests #298

Closed
xvzup opened this issue Aug 21, 2018 · 2 comments · Fixed by #305
Closed

Ignore non matching digests #298

xvzup opened this issue Aug 21, 2018 · 2 comments · Fixed by #305
Labels
kind/bug Something isn't working

Comments

@xvzup
Copy link

xvzup commented Aug 21, 2018

Hi,

I am running Kaniko on Kubernetes (1.9) in Huawei cloud. I use the registry provided by Huawei.
Currently my build fail with the following error messages:

time="2018-08-21T12:28:45Z" level=error msg="manifest digest: "sha256:bc1c0e105251471a09b19d3f12ca4917646548a63c3022f9e0e1b1b3832baabf" does not match Docker-Content-Digest: "bc1c0e105251471a09b19d3f12ca4917646548a63c3022f9e0e1b1b3832baabf" for "x.x.x.x/test1234/docker-pyspark:latest""

The digests are identical, but the manifest digest contains a leading 'sha:'. Is there a way to tell Kaniko to ignore this?

Thx

@priyawadhwa priyawadhwa added the kind/bug Something isn't working label Aug 21, 2018
@dlorenc
Copy link
Collaborator

dlorenc commented Aug 23, 2018

This looks like a possible bug in the huawei registry. The Docker API spec requires the digest to contain the algorithm:

https://docs.docker.com/registry/spec/api/#content-digests

@jonjohnsonjr should we default to sha256 if nothing is specified?

@jonjohnsonjr
Copy link
Contributor

jonjohnsonjr commented Aug 23, 2018

That's definitely a registry bug, but I'm not sure how readily we could get them to fix it...

The client may choose to ignore the header or may verify it to ensure content integrity and transport security. This is most important when fetching by a digest. To ensure security, the content should be verified against the digest used to fetch the content.

I'm okay with just ignoring this header when fetching by tag. We also don't care about the header when fetching by digest, since we just hash the response. Since Docker Hub still hasn't fixed a similar bug on their side, we should probably just treat this header as completely unreliable :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants