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.
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.
You could just ignore Git metadata and bind it to the account which was used to authenticate (pubkey, pass, etc)
Also, imagine the following:
1. Alice writes some code and pushes it to a feature branch. She does not necessarily use github, though she does use git.
2. Bob pulls from Alice's feature branch into a new feature branch. He then pushes to his own repo on github. All commits are rewritten to have Bob as the author.
3. Charlie pulls from Alice's feature branch into a new feature branch. He then pushes to his own repo on github. All commits are rewritten to have Charlie as the author.
4. If we go and bind it to the account, then suddenly everyone's history diverges. Bob and Charlie certainly see different histories. The fact that Alice is the one who actually wrote these commits is completely lost.
I mean, it doesn't even make sense in a common-sense way. Why do I become the 'author' if I just pushed the code to a specific place? If you want to have some chain, force a merge commit every time someone merges.
¹ Well, specifically, they're the commit's committer, but if they did the work, they're the author too. Everything still applies.
% git config --get user.name
% git commit -m "Test" --author "Test Dude
% git log -n 1 --pretty="%cn, %an: %s"
Original Committer, Test Dude: Test
That's a non-standard definition of the term.
This would also be a huge issue for rebase workflows, because rebasing changes the commit SHA. Every commit I rebased would end up belonging to me, not the original author.
It's worth keeping in mind that what GitHub does now is what _every_ other git client does, and it's in GitHub's best interest not to confuse users (or to make it look like they're privileging a GitHub-based workflow over a standard git workflow).
> You may be wondering what the difference is between author and committer. The author is the person who originally wrote the patch, whereas the committer is the person who last applied the patch. So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit — you as the author and the core member as the committer.
Try it by setting the author on a commit you make. Github displays it just fine. I used to use it in school when working with non-comp-sci students on collaborative work (for instance, a report written in LaTeX).
I guess it's a UX issue rather than github security, but I could commit as person_X and include in my commit log a message to @person_Y requesting that they take some action (email account details, send bitcoin to an address, etc) which they would only take if they believed the real person_X had asked them to.
It does seem strange that the same visual user identity is associated with an action like creating an issue (requires authentication as user) and creating a commit "by" that user (does not require authentication as user).
Still would be nice to avoid the duplication though.
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.
In my company's git repo, yes, I want full control.
In a public forum where lots of my public image is tied up, I don't want people to be able to impersonate me.
It's a tricky one to solve, though. Not sure how it would be achieved without demanding that every commit is GPG signed.
That would need to be configurable, though -- it would kind of suck to lose credit for commits just because they weren't merged using GitHub's tools.
May I quote you on that? I think I focused too much on the cool factor and not the problem I was trying to address. (Which you summed perfectly.)
There should be a way to stop these commits from happening under my name without going to the computer physically or rewriting history every time it happens. And that only works if you have access to the repository.
On the other hand, allowing a user to completely restrict the ability to make commits identifying them as the author would mean that J. Q. Hacker could retroactively interfere with any project they had previously committed to simply by enabling that setting.
If you're looking to securely prove who made a commit, look into signing commits.
GitHub does 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.
If you want real verification, sign your commit with GPG/PGP.
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).
Original post: http://www.jayhuang.org/blog/pushing-code-to-github-as-linus...
There is definitely a potential for abuse, but can you solve it without breaking useful functionality?
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).
Two factor auth helps with this, I think.
I haven't tested it, but based on the description, it seems that only the "Primary GitHub Email" would be used for password resets:
Other added emails would thus be used for associating commits but not for regaining account access.
The email address has to be verified, but any of the verified email addresses can be used to reset passwords. There is no way to un-verify an email address besides deleting it and re-adding it.
EDIT: I've confirmed the wording doesn't match the execution, and I've send a message to GitHub
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: http://joshbranchaud.com/blog/2013/06/06/Fun-with-GitHubs-Co...
It was actually a personal private computer until I left that area and opened up the password. I overlooked changing 'git config user.email !@#$'.