-
Notifications
You must be signed in to change notification settings - Fork 545
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
Encourage signing OCI artifacts that *you* produced, not that the registry gives you #2516
Comments
Depending on how the tool implements it, the situation isn't quite this bad. The digest is the sha256 sum of the manifest json, which is pushed as a byte stream, so you can compute that locally without depending on the registry response. That said, I'd still like to see universal support for the OCI Layout so that images can be signed before pushing to the registry. That would avoid race conditions where there are unsigned images in the repo. |
I was trying to sign an image in my docker image store that I've tagged to a specific named tag (
Maybe there could be a flag that cosign uses to read from dockers image storage? |
Unfortunately you can't always sign an image from inside a docker daemon, docker doesn't actually know the digest of an image until it's been pushed to a registry. Some images will have known digests if you pulled it, but that's not always the case and you can't force it to calculate the digest. |
A common workflow is:
$ ko build --image-refs /tmp/refs $ cat /tmp/refs | xargs cosign sign
This is almost good: it avoids signing tags (#2047). But unfortunately those image refs are computed after a roundtrip to the registry, meaning that you (1) built something, (2) sent it to a third party, and (3) signed something that the third party sent back to you. (Same is true for
docker build
.)Ideally, you'd sign something that you built directly. But OCI makes this hard! You don't know the hash of the thing you're signing until you upload it (unless you use layouts).
We need to do a few things here:
cosign
payloads contain a "docker-reference" field which has something likegcr.io/foo:latest
; this payload changes when moving an image fromlocalhost
togcr.io
. We should allow users to set this as the ultimate target? Or maybe not have the docker-reference at all, I'm not sure.cosign sign
of layouts idiomatic (I don't know all the details here)CC @datosh @sudo-bmitch
The text was updated successfully, but these errors were encountered: