What is the difference between cosign sign and cosign sign-blob, and who stores the result?

## The two commands answer different questions about *where the artifact lives* cosign is Sigstore's command-line tool for signing and verifying artifacts. Its subcommands split along a single axis: is the thing you want to sign an object in an OCI registry, or is it a file? ### `cosign sign` — registry-resident artifacts You hand it a registry reference. The subject of the signature is the artifact's content digest (`sha256:...`), not its tag — a tag is a mutable name, a digest is the content. cosign then pushes the signature material into the same registry, so distribution is solved for you: anyone who can pull the artifact can also fetch its signature, and `cosign verify` on the same reference finds it. Because the subject is a digest, signing a tag is a slightly dangerous convenience: cosign resolves the tag to whatever digest it points at *at that moment*, and if the tag moves afterwards the signature does not follow it. Signing and verifying by digest removes that whole class of confusion. ### `cosign sign-blob` — anything else A training checkpoint, a `.deb`, an RPM, a release tarball, an installer script: none of these are registry objects, and `sign-blob` exists for them. It hashes the file, signs the hash, and gives the result back to you as output rather than pushing it anywhere. In keyless mode you get a signature and the short-lived certificate that binds the signing public key to an OIDC identity. `--bundle <file>` collects the signature, the certificate and the transparency-log entry into one file, which is far easier to move around than three separate strings. The verifier counterpart is `cosign verify-blob`, which needs the file, the bundle (or the separate signature and certificate), and the identity you expect. ### Who keeps the material — the part candidates miss With `sign`, the registry keeps it. With `sign-blob`, *you* keep it. Nothing stores it on your behalf: the transparency log records that a signing event happened over a given hash, but it is a log, not artifact storage, and it will not serve your bundle back as a distribution channel. If the bundle is lost, the artifact is unverifiable even though it was legitimately signed. A concrete shape: a data-science platform signs training checkpoints with `sign-blob --bundle` in the job that produces them, and uploads the checkpoint and the bundle together to an object-storage bucket. The loader verifies before deserialising anything. The platform-operations group can also write that bucket, and that is exactly the point — an operator who swaps a checkpoint cannot produce a bundle that verifies against the training job's identity, because they cannot obtain a certificate for that identity. What they *can* do is delete the bundle, so the loader must fail closed when signature material is missing rather than treating "no bundle" as "nothing to check". Storing artifact and bundle in the same bucket is not itself the weakness; treating a missing bundle as a pass is. ### Keys versus keyless Both commands work either way. With `--key`, you supply a key pair and inherit the job of generating, storing and rotating the private key. Without it, cosign runs the keyless flow: an OIDC token is exchanged for a short-lived certificate bound to that identity, and the signing event is recorded in a transparency log. The command shapes above are identical in both modes; only what the verifier pins changes — a public key in one case, an expected identity and issuer in the other. ### What neither command does Neither one inspects the artifact. Signing is an assertion of origin, not a quality judgement: a signature says *who vouched for these exact bytes*. It does not say the artifact is free of vulnerabilities, that it was built from reviewed source, or how it was produced. Those are different claims carried by different mechanisms.