Thanks, we'll try to simplify it.

I'll also try to get simpler instructions on our new website.

Appreciate it, thanks @mholt . I tried to work through some of it, but even the commands as shown appear to be out of date, e.g. cosign in its present v2 appears to now require --certificate-oidc-issuer and --certificate-identity, so it seems its generally in need of an update anyway.

Sure, we can give a one- or two-liner, but I don't agree that a one-liner will help the concerned user with security. The process is multi-step out of necessity because you need you verify every segment of the proof. You received the asset and the signature from the same source, i.e. GitHub release page. An attacker who can falsify the asset can also falsify the signature. The page attempts at explaining how to validate each and every aspect.

Here are the risks at hand:

• Do the 3 artifacts (asset, signature, and cert), as given by the GitHub release page, result in valid signature match?
• Is the certificate/key issued from the expected issuer?
• Does the cert contains the expected values in the expected cert data fields?
• Does the signature match the public record on Rekor?

The article attempts to help you identify each "leg" of the interaction.

• The 3 artifacts, (asset, signature, and cert) together as provided by the GitHub release page, result in valid signature.
• The certificate used for signing is issued by the expected CA
• The resulting signature matches the public record who witnessed the signing event

For now, the one-liner is:

cosign verify-blob \
--certificate-oidc-issuer https://token.actions.githubusercontent.com \
--certificate-github-workflow-name "Release" \
--certificate-github-workflow-ref refs/tags/${TAG} \
--certificate-identity-regexp caddyserver/caddy \
--certificate ./caddy_2.6.4_checksums.txt.pem \
--signature ./caddy_2.6.4_checksums.txt.sig \
--verbose \
./caddy_2.6.4_checksums.txt

We'll add it to the page.

I think as I said @mohammed90 for post people, something to encourage them to do the equivalent of gpg --verify is not a bad thing.

Already too many people don't even do gpg --verify, so the chances of them following pages of individual steps is, well, likely to be a non-starter to put it politely.

Just like with other things in IT security, the sufficiently paranoid can take further steps, but really you need to cater for the majority who when faced with a multi-step process will just say "* that !" and download the binary anyway.

Don't get me wrong, in principle I agree 100% with what you are saying .... but I think we need to have a meeting with Mr Reality here when it comes to Average Joe.

but I think we need to have a meeting with Mr Reality here when it comes to Average Joe.

OK, but take that up with the cryptographic engineers or at least with the sigstore project because there's not much we can do about that.

I think Mohammed's answer is a great one and we will absolutely use it.