GitHub signs all commits by all users with the same key

[vngzs]

We were interested in building some software that doesn't distrust GitHub, but distrusts certain GitHub users and privileges others. Potentially, some of the distrusted users might be GitHub admins.

The obvious solution I had in mind for this was to verify commit signatures using GitHub delegated signing keys. We have a policy of using the GitHub web UI for merges for a few reasons, and in particular the repository in question uses the web UI for commits as well. If we wanted to distrust certain GitHub administrators' commits in this repository, and if GitHub signed each user's commits with their own key, then we could simply check that commits were signed by keys in the (externally maintained) list of trusted pubkeys, and that would be sufficient to prevent administrators from arbitrarily modifying sensitive repository contents.

Alas, in the current GitHub iteration implementing such a control is impossible - GitHub signs every commit with a single 4096-bit RSA key. This doesn't match my intuitive understanding of what a GitHub-signed commit means. I would think that a GitHub signed commit is a proof that the commit author had access to a given user's GitHub web UI at the time of commit authoring.

I'm aware that we could forego the web UI for merges and merge using the CLI. That seems to obviate many important GitHub features such as protected branches, pre-commit code review, enforced status checks, and so on, in addition to preventing contributions from less technical users (who would need to not only use the raw Git interface, but also maintain GPG or SSH commit signing keys).

Are per-user signing keys anywhere on the GitHub security roadmap? It seems like the natural design approach and a stronger security model than the current setup.