-
Notifications
You must be signed in to change notification settings - Fork 551
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
Discourage signing references to images that aren't digests #2047
Comments
It looks like one place we could put the warning is here: cosign/cmd/cosign/cli/sign/sign.go Lines 150 to 160 in dbd430f
with an if _, ok := ref.(name.Tag); ok {
log.Println("hey don't sign tags pls")
} |
See sigstore#2047. Signed-off-by: Zachary Newman <zjn@chainguard.dev>
Don't |
@ChristianCiach Yes, I think whenever you reference a remote image you could potentially have this issue. |
See sigstore#2047. Signed-off-by: Zachary Newman <z@znewman.net>
See sigstore#2047. Signed-off-by: Zachary Newman <z@znewman.net>
Before resolving, make sure to:
|
Please also make sure that references like |
See sigstore#2047. Signed-off-by: Zachary Newman <zjn@chainguard.dev>
See sigstore#2047. Signed-off-by: Zachary Newman <zjn@chainguard.dev>
* Update warning when users sign images by tag. See #2047. Signed-off-by: Zachary Newman <zjn@chainguard.dev> * Fix lots of docs Signed-off-by: Zachary Newman <zjn@chainguard.dev> * Add test cases for no-digest warning message Also explicitly check for Digest being set, rather than Tag not being set. This doesn't actually make a difference because name.ParseReference just throws away the tag in such cases (maybe a bug), but it does make the intent clearer. Signed-off-by: Zachary Newman <zjn@chainguard.dev> Signed-off-by: Zachary Newman <zjn@chainguard.dev>
FYI #2313 just merged. It only covers There's still a lot to do. Next steps:
|
I would like to do this for
Any plans for this? |
Excellent, go for it! FYI you can just make the breaking change if you do it before the Cosign 2.0 release, no need to bother with a deprecation period. Let us know if you'd like any guidance.
Long-term, yes. But I think this is blocked on a few other things:
|
FWIW, as the original author of the c/image “simple signing” payload format, I think this should be exactly the opposite: discourage signing digest references. Or, to be more precise, the signing operation must point at an image by digest[1] — but the signed payload should name the image, in First, a technical note: the signature payload, both as originally specified and as created by Actually, Cosign enforces that the cosign/pkg/cosign/verifiers.go Line 44 in 0081e1a
critical.identity.docker-reference , so putting a digest in the identity field would be not just redundant, but possibly also misleading.
Now, as to the main reason: There are basically two reasons to sign an image: nonrepudiation (for which just the pair of One of the ways an untrusted transport can attack users is to substitute different “legitimate” images, correctly and intentionally signed by the intended author — causing the user to use a different image than the one that was intended. For example, a malicious registry might, when asked for The protection against this should be effortless, based only on existing data. Users are unlikely to carry around an extra version number around, in addition to the minimal required deployment configuration (e.g. a k8s Pod spec), and users can not be reasonably expected to actively do an extra step (and to never forget) in order not to be vulnerable AFAICS, about the only practical UI for this is to match the deployment instruction (image name in And that’s why the Now, Cosign might or might not share the view that this kind of protection against substitution attacks is important, or practical enough to enforce; so Cosign might or might not decide to enforce name:tag verification by default. But I’d very much like for The end-user UI for cosign sign --digest sha256:… registry.example.com/namespace/name:tag where the The above is the basic use case; some users may require more control, with cosign sign --digest sha256:… --sign-identity registry.example.com/production-namespace/name:released-tag \
registry-staging.example.com/staging-namespace/name:released-tag-staging to decouple the signed identity from the physical location of the image that is being signed [1] (which is best exposed by not having a separate signing operation, but by integrating signing into a |
Yes. I think the argument was more that a malicious (or even a non-malicious) registry or user could simply change the
I think that's fine. The spirit of this issue is more around verifying the digest and was perhaps just making the assumption about the UI. For example, if this solution is adopted a warning could be printed to users encouraging them to use the |
If you run
cosign sign container.registry.io/foo:tag
, then you're vulnerable to::tag
changed. Immutable tags help with this, but it's hard for cosign to know whether a registry's tags are immutable.It's much more meaningful to sign the digests, which are immutable.
In Slack discusssion, @imjasonh writes:
I think this is a good idea.
The text was updated successfully, but these errors were encountered: