I don't consider "verified" in the GitHub UI as safe to rely on.
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.
The "verified" checkmark in GitHub UI is not really a big reassurance. Someone can steal your private key, continue to use it and still be verified until you or someone else notices and revokes the key.
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.
smimesign supports timestamping with a normal timestamp server, with a bit of extra effort. It would be cool if your tool could (at least optionally) do the same as an alternative to your custom transparency log.
We used to actually run an RFC3161 timestamp server in addition to the transparency log but recently turned it down because no one was using it. I'd like to bring it back for stuff like this.
* 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"