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.
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.
Except that would make the view of the log look terrible, because there are all kinds of times where the person who pushes is not the person who committed. If 10 people on my team each do a commit on our cool local branch, and I happen to be the one who pushes the branch to git, do all of the changes show up with my name?
What's accurate here? The guys who committed are the guys who are noted as the commit author¹. Just because I pushed the commits to a specific branch of a repo doesn't make me the author of the commit.
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.
Since showing what `git log` actually contains is the definition of 'accurate', I'm not sure what you mean. They aren't "delegated commits", it's the nature of distributed version control: Github's copy of the repo doesn't get to claim special authority over other copies.
I would define accurate as a combination of 'git log' and which account pushed to github. As it is, github seems to treat these commits differently (they aren't showing up on the other users' pages...at least as far as I can tell) so it seems like something that should be indicated in this UI as well.
In a git repo, history is shown with `git log`, so when I ask GitHub to show me the history of the repo, it ought to match `git log`. That's not "non-standard".
But in that case, if I pushed commits from another person (that they sent me over email, for instance) I would end up falsely claiming credit for their work.
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.
Perhaps in situations where the uploading user and the committing user differ, it could read something like "X on behalf of Y". This seems like it would satisfy OP's concerns as well as yours.
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).
This exists in Git and Github accommodates it just fine. See [0] for the following explanation:
> 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).
The opposite issue is also capable of happening. Don't misunderstand, I completely acknowledge the fact that this is a very difficult issue to solve and fundamental to git design.
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).
I don't think this prevents that requirement from being met -- you can attach a signature to the commit, or keep a separate record of signatures for each commit.
Still would be nice to avoid the duplication though.
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.
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.
It seems like it'd be possible to at least restrict your GitHub account from appearing linked to a commit unless it's a repo you've contributed to directly (by pushing or with a pull request).
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.
I acknowledged that. It's one of those features that isn't perfect when implemented.
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.
I think it would be reasonable to allow a GitHub user to control whether their account is linked to commits (say, to require the commit be signed).
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.
That would break the distributed nature of Git: if you'd committed to code locally, and I pulled from you, I'd then not be able to push any changes I made up to GitHub, because the change set included commits from you.
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.
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).
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.
There is definitely a potential for abuse, but can you solve it without breaking useful functionality?
Agreed, but GitHub doesn't show any indication that a commit has a valid GPG signature, so a casual visitor to GitHub wouldn't know if a commit is genuine or not.
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.
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).
The reason it seems that way to you is because you haven't tested it.
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.
If that's the case, I'll be reaching out to GitHub to clarify the wording once my test shows otherwise. I specifically pointed out that I was basing my understanding on the message they provide.
EDIT: I've confirmed the wording doesn't match the execution, and I've send a message to GitHub
Thanks! I sent them an email a year or two ago and they haven't addressed it. It is a bit of an edge case, and there's a workaround. So I'm not annoyed that they haven't fixed it, but I will be glad when they do.
As several others have pointed out, this isn't a security issue or a bug, it's just how Git works.
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...
I doubt it. If you follow the links to individual usernames, you'll see that they don't even get credit for the commit that might have been made on their behalf. (Although the person who actually committed got credit for their commits.)
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.
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.