Hey Security friends: Does git commit signing matter?
I feel like I don't see it used in production as much as I would expect, and I also don't see a big push on it from the wider sec community.
Do we care?
@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.
@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
@aschmitz @phildini (for example, one could simply add a commit to a working branch rather than try adding it to the main branch, and the next time the working branch is rebased, it gets a signature from the unawares contributor. at this point, the signature means nothing)