Any way to guarantee that a git user doesn't use fake account info when commiting and pushing?

问题

Since git users can config their user.name and user.email freely and do commits, it's possible for John to fake a commit with Bob's name and email, which is not what we want. Is there any way to prevent this? I know in svn we need username and password to commit; is there any equivalent mechanism in Git?

回答1:

Some convoluted solutions are possible, I guess:

Require an SSH account to access a repository; create one repository per authorized user.
Create hooks in every repository that rewrite the pushed to commits to include information of the author the repository “belongs to.”
After rewriting, push everything to a main repository.

This solution is not only a pain in the ass but also prone to rewrite and mis-attribute commits from other persons that the author included from a co-worker or somebody else.

gitosis or gitolite might offer some functionality like that, too, I don’t know, I’ve never used them.

Personally, I would simply prefer not to work with people who would seriously hamper with a commit’s author information.

回答2:

Consider requiring commits to be signed with a gpg key?

http://mwop.net/blog/236-GPG-signing-Git-Commits and reject anything submitted without one. This would allow you to verify whoever committed the change (possibly with some work this could be automated on the server)

Alternatively the implemenation of a peer review system to double check stuff before merging could resolve this issue (allowing trusted\other stuff to double check the changes (though getting them to review every commit would be a bit annoying)) Using a tool like gerrit would probably be the best system for this. Though a simple version could be created with gitolites permission system.

Gitolite would allow you to specify namespace (and repo) permissions. Allowing you to control access to various areas and having production code restricted to only trustable people that review and merge the changes.

Though all of this is asking for a technological solution to a sociological issue. My preferred recommendation would be the "Mallet of Loving Correction."

回答3:

Another way, also based on signed gpg, is to sign the push operation itself (and not a object, like a tag or a commit)

That is what proposes Git 2.2 (November 2014), with commit a85b377, by Junio C Hamano (gitster):

`push`: the beginning of "`git push --signed`"

While signed tags and commits assert that the objects thusly signed came from you, who signed these objects, there is not a good way to assert that you wanted to have a particular object at the tip of a particular branch.
My signing v2.0.1 tag only means I want to call the version v2.0.1, and it does not mean I want to push it out to my 'master' branch---it is likely that I only want it in 'maint', so the signature on the object alone is insufficient.

The only assurance to you that 'maint' points at what I wanted to place there comes from your trust on the hosting site and my authentication with it, which cannot easily audited later.

Introduce a mechanism that allows you to sign a "push certificate" (for the lack of better name) every time you push, asserting that what object you are pushing to update which ref that used to point at what other object.

Think of it as a cryptographic protection for ref updates, similar to signed tags/commits but working on an orthogonal axis.

The basic flow based on this mechanism goes like this:

You push out your work with "git push --signed".

The sending side learns where the remote refs are as usual, together with what protocol extension the receiving end supports.
If the receiving end does not advertise the protocol extension "push-cert", an attempt to "git push --signed" fails.
Otherwise, a text file, that looks like the following, is prepared in core:

certificate version 0.1
pusher Junio C Hamano <gitster@pobox.com> 1315427886 -0700

7339ca65... 21580ecb... refs/heads/master
3793ac5... 12850be... refs/heads/next

The file begins with a few header lines, which may grow as we gain more experience.
The 'pusher' header records the name of the signer (the value of user.signingkey configuration variable, falling back to GIT_COMMITTER_{NAME|EMAIL}) and the time of the certificate generation.
After the header, a blank line follows, followed by a copy of the protocol message lines.

Each line shows the old and the new object name at the tip of the ref this push tries to update, in the way identical to how the underlying "git push" protocol exchange tells the ref updates to the receiving end (by recording the "old" object name, the push certificate also protects against replaying).
It is expected that new command packet types other than the old-new-refname kind will be included in push certificate in the same way as would appear in the plain vanilla command packets in unsigned pushes.

The user then is asked to sign this push certificate using GPG, formatted in a way similar to how signed tag objects are signed, and the result is sent to the other side (i.e. receive-pack).

In the protocol exchange, this step comes immediately before the sender tells what the result of the push should be, which in turn comes before it sends the pack data.

When the receiving end sees a push certificate, the certificate is written out as a blob. The pre-receive hook can learn about the certificate by checking GIT_PUSH_CERT environment variable, which, if present, tells the object name of this blob, and make the decision to allow or reject this push. Additionally, the post-receive hook can also look at the certificate, which may be a good place to log all the received certificates for later audits.

Because a push certificate carry the same information as the usual command packets in the protocol exchange, we can omit the latter when a push certificate is in use and reduce the protocol overhead.