I'm not 100% sure what you're saying here, but in the post you linked, Linus seems to be referring to a hypothetical solution where you're not signing the SHA o

I'm not 100% sure what you're saying here, but in the post you linked, Linus seems to be referring to a hypothetical solution where you're not signing the SHA of a commit but some subset. When you use Git to sign a commit or a tag, you vouch for the SHA of that commit or tag; i.e. the whole history of that branch up to that point, including author names and email addresses. The point Linus is making is not exactly one of security. The problem you get when signing commits instead of tags is that the signatures become part of the branch's history and both (signature and history) become inseparable. You can't re-sign a commit without re-writing all the commits that follow. If for example your keys were compromised, you invalidated them, and want to re-sign your repo with your new keys, you'll have to change each and every commit. With a tag, you'll just update the tags and the rest of the branch remains unchanged. I hope, together with the thread you posted, this at least makes some sense. Back to GitHub: I think this is a nice UI for displaying signatures in the history view. Assuming you can trust GitHub to really use your public key for validating (hat tip to fabulist) I don't see an issue with making that information accessible via the web. More importantly, they also display the "verified" badge on the "Releases" page where your tags appear.