What you might not realise is that the author of a commit is not related to the (authenticated) user who pushes.
You couldn’t merge changes from multiple people otherwise.
Signed commits do fix this although you have to be careful about your threat model. Lots of software (e.g. gitlab) will prevent alice from pretending to be bob but will not protect you against server compromise (because public key directory and signing enforcement are done on the server).
Working at an org which does signed commits, it doesn’t buy us quite as much as we would like.
Also, if you enforce signing you can’t mash a server-side “merge” button anymore because that commit would need to be signed...
This complicates the pr/mr workflow for teams and increases resistance from those who don’t see the value in signing.
What I mean is that making fake author accounts and then merging with an authenticated account shouldn’t help a malicious actor. Any competent project will be interested in the accounts contributing.
Maybe my org is just simple but if “John Doe” started submitting pull requests and prepend merged them, it’s me on the hook and there are people interested in who John Doe is. And in my org, even John Doe needs a network credential so even their local git instance (which I’ve never seen anyone use) would need a credential.
> but will not protect you against server compromise (because public key directory and signing enforcement are done on the server)
Which is why it's important for the security team to directly manage and be responsible for the code repository server. Usually the server also stores all the git repositories in some filesystem directory, meaning that server compromise would allow an attacker to remove all the company's code, regardless of permissions set for those repositories, and potentially leak it.
You couldn’t merge changes from multiple people otherwise.
Signed commits do fix this although you have to be careful about your threat model. Lots of software (e.g. gitlab) will prevent alice from pretending to be bob but will not protect you against server compromise (because public key directory and signing enforcement are done on the server).
Working at an org which does signed commits, it doesn’t buy us quite as much as we would like.
Also, if you enforce signing you can’t mash a server-side “merge” button anymore because that commit would need to be signed...
This complicates the pr/mr workflow for teams and increases resistance from those who don’t see the value in signing.