Encourage signing OCI artifacts that *you* produced, not that the registry gives you

[znewman01]

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:

• Docs and education: make sure folks understand that, mostly for the OCI use case.
• Try to get upstream tools to not have this problem, by producing OCI layouts: track bugs against ko (Signing built images ko-build/ko#357) etc.
• cosign payloads contain a "docker-reference" field which has something like gcr.io/foo:latest; this payload changes when moving an image from localhost to gcr.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.
• Making cosign sign of layouts idiomatic (I don't know all the details here)

CC @datosh @sudo-bmitch

[sudo-bmitch]

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).

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.

[kpcyrd]

I was trying to sign an image in my docker image store that I've tagged to a specific named tag (cosign sign sh4d0wup), this name was parsed into docker.io/_/sh4d0wup and a pull failed because it doesn't exist:

% Run cosign sign sh4d0wup
Generating ephemeral keys...
Retrieving signed certificate...

        Note that there may be personally identifiable information associated with this signed artifact.
        This may include the email address associated with the account with which you authenticate.
        This information will be used for signing this artifact and will be stored in public transparency logs and cannot be removed later.
Successfully verified SCT...
WARNING: Image reference sh4d0wup uses a tag, not a digest, to identify the image to sign.

This can lead you to sign a different image than the intended one. Please use a
digest (example.com/ubuntu@sha256:abc123...) rather than tag
(example.com/ubuntu:latest) for the input to cosign. The ability to refer to
images by tag will be removed in a future release.
Error: signing [sh4d0wup]: accessing entity: GET https://index.docker.io/v2/library/sh4d0wup/manifests/latest: UNAUTHORIZED: authentication required; [map[Action:pull Class: Name:library/sh4d0wup Type:repository]]
main.go:62: error during command execution: signing [sh4d0wup]: accessing entity: GET https://index.docker.io/v2/library/sh4d0wup/manifests/latest: UNAUTHORIZED: authentication required; [map[Action:pull Class: Name:library/sh4d0wup Type:repository]]
Error: Process completed with exit code 1.

Maybe there could be a flag that cosign uses to read from dockers image storage?

[dlorenc]

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.