Don't jump in without reviewing the caveats:
* Not supported as "verified" in the GitHub UI [edit: mostly as opposed to "the main reason to try it"]
* A public transparency log "which may include user emails or repo identifiers"
* Not supported as "verified" in the GitHub UI [edit: mostly as opposed to "the main reason to try it"]
* A public transparency log "which may include user emails or repo identifiers"
If you forge a commit from Linus Torvalds, where Joe Blow is the co-author, as long as Joe Blow GPG signed the commit it will show "Verified" with no distinction indicating Linus did not.
This combined with other issues I reported to GitHub like this[0] ('working as intended', but now thankfully fixed because it blew up on Twitter months later) makes me think GitHub doesn't care to invest a whole lot in commit verification stuff.
My point was more that the show (which many would consider using it for) isn't even working yet for this project.
So, yes you can of course have Verified name spoofing, but at least the email in git commits can be trusted.
GitHub, for example, has their own GPG key as verified for commits you author on their UI. In this case, you're trusting GitHub –and GitHub can also mark sigstore certificates as verified as well (they should), as they're actually verifiable using a transparency log.
What sigstore really brings to the picture is the attestation of "whoever signed this commit was actually signed into the github account @foo –or google account bar@google.com at the time, and here's the proof in a transparency log" –and those accounts can be secured by 2FA. It also takes you out of GPG key management business which I personally despise.
(https://github.com/github-community/community/discussions/77... - released by end of June)
https://github.com/github/smimesign/issues/47#issuecomment-4...