4 ms·

Why does GitHub let me commit as other people?

45 points by gluxon 12y ago

Afforess 12y ago
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.
- davidbanham 12y ago
  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.
  - djur 12y ago
    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.
  - click170 12y ago
    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.
  - gluxon 12y ago
    @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.)
- gluxon 12y ago
  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.
  - djur 12y ago
    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.
  - akerl_ 12y ago
    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.
yeukhon 12y ago
This has been reported many times. http://www.jayhuang.org/blog/tag/impersonating/ 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).
shravan 12y ago
Discussed earlier here: https://news.ycombinator.com/item?id=6918343 https://news.ycombinator.com/item?id=6918343 Original post: http://www.jayhuang.org/blog/pushing-code-to-github-as-linus-torvalds/ http://www.jayhuang.org/blog/pushing-code-to-github-as-linus...
agwa 12y ago
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?
- mitchty 12y ago
  GPG sign your commits in git if its an issue.
  - agwa 12y ago
    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.
    - erichurkman 12y ago
      Even git itself does not show signature information by default in `git log` and friends.
smoyer 12y ago
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.
- akerl_ 12y ago
  I sure hope a public computer doesn't have a private key that has credentials to push as him to GitHub :)
  - gluxon 12y ago
    It doesn't. :) It was actually a personal private computer until I left that area and opened up the password. I overlooked changing 'git config user.email !@#$'.
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
akerl_ 12y ago
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.
djur 12y ago
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.
- iancarroll 12y ago
  > 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)
  - djur 12y ago
    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.
    - gluxon 12y ago
      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.
    - shawnz 12y ago
      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.
      - 12y ago
panzi 12y ago
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.
deleted 12y ago
[deleted]
albertyw 12y ago
I think this is a use case of signed commits. They would allow for verification of the commit's author's identity.
benatkin 12y ago
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.
- akerl_ 12y ago
  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 https://github.com/settings/emails Other added emails would thus be used for associating commits but not for regaining account access.
  - benatkin 12y ago
    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.
    - akerl_ 12y ago
      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
      - 12y ago
harlanji 12y ago
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.
sysop073 12y ago
Also, I hear you can send e-mail claiming to be from anyone!
deleted 12y ago
[deleted]
cmelbye 12y ago
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-Contribution-Graphs.html http://joshbranchaud.com/blog/2013/06/06/Fun-with-GitHubs-Co...
- jaredsohn 12y ago
  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.)
YTowOnt9 12y ago
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.

45 points by gluxon 12y ago

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.

davidbanham 12y ago
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.
- djur 12y ago
  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.
- click170 12y ago
  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.
- gluxon 12y ago
  @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.)
gluxon 12y ago
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.
- djur 12y ago
  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.
- akerl_ 12y ago
  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.

yeukhon 12y ago

This has been reported many times. http://www.jayhuang.org/blog/tag/impersonating/ 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).

shravan 12y ago

Discussed earlier here: https://news.ycombinator.com/item?id=6918343 https://news.ycombinator.com/item?id=6918343 Original post: http://www.jayhuang.org/blog/pushing-code-to-github-as-linus-torvalds/ http://www.jayhuang.org/blog/pushing-code-to-github-as-linus...

agwa 12y ago

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?

mitchty 12y ago
GPG sign your commits in git if its an issue.
- agwa 12y ago
  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.
  - erichurkman 12y ago
    Even git itself does not show signature information by default in `git log` and friends.

smoyer 12y ago

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.

akerl_ 12y ago
I sure hope a public computer doesn't have a private key that has credentials to push as him to GitHub :)
- gluxon 12y ago
  It doesn't. :) It was actually a personal private computer until I left that area and opened up the password. I overlooked changing 'git config user.email !@#$'.

deleted 12y ago

[deleted]

deleted 12y ago

[deleted]

akerl_ 12y ago

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.

djur 12y ago

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.

iancarroll 12y ago
> 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)
- djur 12y ago
  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.
  - gluxon 12y ago
    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.
  - shawnz 12y ago
    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.
    - 12y ago

panzi 12y ago

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.

deleted 12y ago

[deleted]

albertyw 12y ago

I think this is a use case of signed commits. They would allow for verification of the commit's author's identity.

benatkin 12y ago

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.

akerl_ 12y ago
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 https://github.com/settings/emails Other added emails would thus be used for associating commits but not for regaining account access.
- benatkin 12y ago
  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.
  - akerl_ 12y ago
    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
    - 12y ago

harlanji 12y ago

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.

sysop073 12y ago

Also, I hear you can send e-mail claiming to be from anyone!

deleted 12y ago

[deleted]

cmelbye 12y ago

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-Contribution-Graphs.html http://joshbranchaud.com/blog/2013/06/06/Fun-with-GitHubs-Co...

jaredsohn 12y ago
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.)

YTowOnt9 12y ago

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.