Post #1579421

2026-04-22 17:39 UTC

@phildini In the abstract, assuming no need for deniability, having it is better than not having it, but as with most things it comes down to your threat model. If you don't trust your Git repository host to not tamper with things, then it's useful. If you only sign with touch-activated Yubikeys and validate it before deploys, it could be useful. If you sign with the same SSH keys you auth to GitHub with, and you trust GitHub and have your accounts there locked down, it doesn't get you much.

Replies (2)

@aschmitz@ostatus.lardbucket.org 2026-04-22 17:41

@phildini In larger or more distributed projects, it can be easier than hoping everyone involved has good hygiene around their accounts, so there's some value in it. And given infinite resources, sure, go for it. But for most people, I think you'll have a better cost/benefit ratio from other things, like tightening up CI, cleaning your environment up, locking down your production servers, auditing account access, etc.

Open ##1579422
@Lady@glitch.cat.family 2026-04-22 17:59

@aschmitz @phildini signing only verifies information about the committer, not the author, so there is still a high degree of trust involved regarding the authorship of code. it gives you confirmation that the person who git says committed the code was the actual committer, meaning it can work in tandem with other processes you have for committers like verifying authenticity of commits and ensuring licensing rights. if you don’t have defined processes for committers, then a provenance chain that goes back to them (and stops there) does not get you much in my experience

Open ##1579426