Why does GitHub let me commit as other people?(gluxon.com)
gluxon.com
Why does GitHub let me commit as other people?
http://gluxon.com/blog/2014/05/23/Why-does-GitHub-let-me-commit-as-other-people
55 comments
> The only way to avoid 'spoofing' commits would be to require them to be signed.
You could just ignore Git metadata and bind it to the account which was used to authenticate (pubkey, pass, etc)
You could just ignore Git metadata and bind it to the account which was used to authenticate (pubkey, pass, etc)
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.
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.
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.
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.
"Y via X" would be preferable.
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).
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).
[0] http://git-scm.com/book/en/Git-Basics-Viewing-the-Commit-His...
> 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).
[0] http://git-scm.com/book/en/Git-Basics-Viewing-the-Commit-His...
I've never had success with passing a rebase around the team, only on a local branch. What's your workflow look like w.r.t. rebasing?
Not only that, but if you push a pre-existing repo to github, you'd lose all information about actual authorship.
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?
Maybe the preservation of "delegated commits" is not as important as keeping the commit history accurate?
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.
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.
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.
It could make sense for future versioning systems to separate author from committer.
git supports this:
% git config --get user.name
Original Committer
% git commit -m "Test" --author "Test Dude <[email protected]>"
% git log -n 1 --pretty="%cn, %an: %s"
Original Committer, Test Dude: Test
% git config --get user.name
Original Committer
% git commit -m "Test" --author "Test Dude <[email protected]>"
% git log -n 1 --pretty="%cn, %an: %s"
Original Committer, Test Dude: Test
I believe PCI compliance requires signed commits. There needs to be proof of who committed each line.
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.
Still would be nice to avoid the duplication though.
> what's the security issue here?
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 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).
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'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's a useful feature in git, but a bug in github.
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.
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.
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.
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.
@davidbanham
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.)
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.)
Why is PGP signing an unacceptable solution in your use case? It sounds like that's what I would do given a pressing need to ID a committer.
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.
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.
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'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.
This has been reported many times.
http://www.jayhuang.org/blog/tag/impersonating/
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).
http://www.jayhuang.org/blog/tag/impersonating/
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).
Discussed earlier here: https://news.ycombinator.com/item?id=6918343
Original post: http://www.jayhuang.org/blog/pushing-code-to-github-as-linus...
Original post: http://www.jayhuang.org/blog/pushing-code-to-github-as-linus...
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?
There is definitely a potential for abuse, but can you solve it without breaking useful functionality?
GPG sign your commits in git if its an issue.
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.
Even git itself does not show signature information by default in `git log` and friends.
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.
Also, I hear you can send e-mail claiming to be from anyone!
[deleted]
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).
Two factor auth helps with this, I think.
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.
EDIT: After testing, my statement below is wrong. I've hit up GitHub to see if they'll fix either the wording or behavior.
I haven't tested it, but based on the description, it seems that only the "Primary GitHub Email" would be used for password resets:
https://github.com/settings/emails
Other added emails would thus be used for associating commits but not for regaining account access.
I haven't tested it, but based on the description, it seems that only the "Primary GitHub Email" would be used for password resets:
https://github.com/settings/emails
Other added emails would thus be used for associating commits but not for regaining account access.
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.
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
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...
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.)
[deleted]
[deleted]
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.
I think this is a use case of signed commits. They would allow for verification of the commit's author's identity.
[deleted]
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.