TL;DR needed for Signature Verification page

[udf2457]

Coming to this from the perspective someone used to the gpg --verify world and new to Sigstore, there is an awful lot of waffle on the signature verification page.

A TL;DR at the top of the page is desperately needed, ideally with a one-liner (if possible) but if not just a straightforward TL;DR "this is the list of commands".

If you really want to help people embrace Sigstore as the "new best thing", then making them figure out what the process is through a long rambling page is not the way to do it. At the moment, frankly, I'm left with the impression that I wish Caddy just published a GPG sig like everyone else because as you present it, Sigstore verification looks awfully time-consuming and induces the conclusion that I "can't be bothered", whish of course is technically wrong but humans are humans... don't make it difficult to figure out what needs to be done !

[mholt]

Thanks, we'll try to simplify it.

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

[udf2457]

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.

[mohammed90]

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.

[udf2457]

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.

[mholt]

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.