Is `cosign verify --key https://...` a foot-gun?

[znewman01]

Added in https://github.com/sigstore/cosign/issues/247 to support a use case like:

cosign verify \
    --url https://raw.githubusercontent.com/image-publishing-org/project-repo/$RELEASE_TAG/cosign.pub \
    gcr.io/image/to/verify:$RELEASE_TAG

This seems to get used in a few places:

• Misc. places in our docs.
• Distributing keys for SUSE's signed images
• Distributing keys for Istio's signed images

We could:

1. Leave it.
2. Rip out --key https:// with the logic that you can just pass --key <(curl ...)
3. Require that HTTP-fetched keys also have a --fingerprint flag passed. This would support the "easy one-liner in our docs on image verification" use case.

The argument against (3) is that it doesn't support any notion of rotation (a BYO PKI situation would be a little better). The argument against (2)/(3) is that it's kinda security theater: if we're worried so much about https://istio.io/misc/istio-key.pub being compromised, why couldn't the attacker also modify https://istio.io/latest/docs/ops/best-practices/image-signing-validation/ ?

[sigwinch28]

I think another argument here is that any form of key verification the user wants to perform is inherently racy with the use of the --url flag with the current form of the verify command.

Since the verify command doesn't output either the public key or its fingerprint there is a race condition between running verify and the user fetching the key out of band to verify it somehow. Something like curl ... -o key.pub; run-some-verification-steps key.pub; cosign verify --key key.pub would avoid the race condition.