The author of a commit in git is just metadata. You can set it to whatever you want. This is a necessary feature for distributed workflows, or any kind of workflow where one person may be committing on another person's behalf.<p>The only way to avoid 'spoofing' commits would be to require them to be signed. Anything else would require a single source of authority on the identity of a given committer, which would defeat the purpose of a distributed VCS.<p>The OP mentions "security": what's the security issue here? Being able to label a commit as being from defunkt doesn't give you access to anything defunkt has access to.
This isn't a github problem, git lets you set your user.name and user.email as anything you like. In addition, you can rebase and rewrite the history to change former commits to be from whomever you like.<p>It's a feature, not a bug - this is how git is able to seamlessly interoperate with other VCS, like SVN. The SVN user id and email is displayed as the git commit author. Having to verify this information would be very complicated and essentially break interoperability between VCS's. In addition, mutable history means you could go back and fix up the history, remove misspellings from names, update your git repo to show a new email address, etc. Git follows the standard user philosophy of letting unix users do what they want, and simply warning them if they push rewritten history to a repository.
This isn't a "security problem", nor is it something on GitHub's end. The email used to author a commit is set by the person making the commit, and shouldn't be taken as a secure value or proof that the person who owns that email made that commit. Think of it like the return address on an envelope, not the barcode on a driver's license.<p>If you're looking to securely prove who made a commit, look into signing commits.<p>GitHub <i>does</i> require that you have a valid SSH key for a GitHub user, and that the given GitHub user has access to write to the repo you're pushing to, but that's totally separate from commit messages and authorship.
This has been reported many times.<p><a href="http://www.jayhuang.org/blog/tag/impersonating/" rel="nofollow">http://www.jayhuang.org/blog/tag/impersonating/</a><p>If you want real verification, sign your commit with GPG/PGP.<p>Some people don't use real email address for privacy reason (not sure if email address is really required to commit). Another reason why Github may not want to implement verification is all the people you have written code with... like when you want to push an existing repo to Github. Why? Because Git as a tool is pretty good at rewriting history (unlike Mercurial).
It's because Git is decentralized, and when you push a repo to GitHub it could contain genuine commits from other people that you've pulled into your repo from some other, non-GitHub source. There's no way for GitHub to authenticate such commits.<p>There is definitely a potential for abuse, but can you solve it without breaking useful functionality?
It's because Git includes the author name and email in the commit (remember setting the config?)... if they added any info post-commit on the server it would change the digest which would break tracking for the pushing author. They could easily reject commits that come from emails that don't match the email associated with the account since a key can only be used by one account, but that would break the decentralized Git model of accepting commits and pushing them upstream and mirrors since not Git development happens through GitHub. There might be some kind of solution related to confirming emails are associated with a key, but for the most part it's a function of the Git model and any solution will break some legitimate use cases.
One small problem is that github uses email addresses both for associating commits and for password resets. This means that if someone used their company email account for commits to an open source project, and left the company, once they removed the email address from their account, their commits would no longer be associated. Or, they could leave their email address in their account, but if someone hacked it they could use it to initiate a password reset.<p>It would be nice if in the list of email addresses there was something showing whether it can be used to recover their account, and the ability to change it (requiring them to have at least one email address that can be used with account recovery).<p>Two factor auth helps with this, I think.
As several others have pointed out, this isn't a security issue or a bug, it's just how Git works.<p>However, it does make me wonder something. Do these spoofed commits count towards the "Contributions" visualization on GitHub user profile pages? I wonder if you could do this but on other people's profile pages: <a href="http://joshbranchaud.com/blog/2013/06/06/Fun-with-GitHubs-Contribution-Graphs.html" rel="nofollow">http://joshbranchaud.com/blog/2013/06/06/Fun-with-GitHubs-Co...</a>
I sure hope the "public computer" in your workspace has a private key that matches a public key submitted to Github ... I know Gitolite won't allow this to happen but I'll have to check on GitLab and GitBucket.
That's a well known property of git/hg/distributed version control. If you want to be sure about who made which commit you need to use commit signing. It's the only way to be sure about such things anyway.
It'd be pretty good if the publicity surrounding this article led to an increase in usage of PGP. I've always thought it was a shame how underused asymmetric encryption is in comparison to its potential.