#Mystery digest
1 messages · Page 1 of 1 (latest)
huh.. weird. The renovate version in my CI showed up as an older version, hence why I assumed it was an older tag. And when I didn't find it in docker.io I was further confused. I don't know what the .sig sha means. Definitely not related to dagger.
Yeah, not Dagger-related. It looks like that tag contains custom OCI objects, perhaps signature information?
It could be either to 1) signature / SBOM magic, or 2) multi-arch
perhaps. good lesson for me to actually search for the full SHA instead of eyeballing it
But it's weird that none of the tags actually point to that SHA
right? ok good that I'm not alone in thinking that
My guess is that they do, in a weird indirect way not currently visible in the Docker Hub UI
If you want to get to the bottom of it, I recommend getting one of those OCI registry analyzer tools, it will probably get you the answer quickly
And the pulled artifacts all refer to this sig sha that is not the directly linked sha to the actual image you are pulling.
Didn't know they existed. I'll look into it. Thank you!
Looks like it's something cosign does
Sorry - not the analysis, but pushing <SHA>.sig tag
$ tkn bundle push us.gcr.io/dlorenc-vmtest2/pipeline:latest -f task-output-image.yaml
Creating Tekton Bundle:
- Added TaskRun: to image
Pushed Tekton Bundle to us.gcr.io/dlorenc-vmtest2/pipeline@sha256:124e1fdee94fe5c5f902bc94da2d6e2fea243934c74e76c2368acdc8d3ac7155
$ cosign sign --key cosign.key us.gcr.io/dlorenc-vmtest2/pipeline@sha256:124e1fdee94fe5c5f902bc94da2d6e2fea243934c74e76c2368acdc8d3ac7155
Enter password for private key:
tlog entry created with index: 5086
Pushing signature to: us.gcr.io/dlorenc-vmtest2/demo:sha256-124e1fdee94fe5c5f902bc94da2d6e2fea243934c74e76c2368acdc8d3ac7155.sig
(that's from the cosign README: https://github.com/sigstore/cosign)
So that explains why there's a <SHA>.sig tag, but not why there's no tag pointing to that SHA as far as Docker Hub can tell, even though you end up getting that SHA when you pull