
Why does GitHub let me commit as other people? - gluxon
http://gluxon.com/blog/2014/05/23/Why-does-GitHub-let-me-commit-as-other-people
======
djur
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
> 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
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.

~~~
shawnz
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.

~~~
djur
"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).

------
Afforess
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
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
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.

------
akerl_
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.

------
yeukhon
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
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...](http://www.jayhuang.org/blog/pushing-code-to-github-as-linus-
torvalds/)

------
agwa
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
GPG sign your commits in git if its an issue.

~~~
agwa
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
Even git itself does not show signature information by default in `git log`
and friends.

------
harlanji
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
Also, I hear you can send e-mail claiming to be from anyone!

------
benatkin
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_
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
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_
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

~~~
benatkin
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.

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

~~~
jaredsohn
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.)

------
smoyer
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_
I sure hope a public computer doesn't have a private key that has credentials
to push as him to GitHub :)

~~~
gluxon
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 !@#$'.

------
panzi
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.

------
YTowOnt9
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.

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

