
Linus Torvalds did not commit this - daenz
https://github.com/amoffat/masquerade/commit/9b0562595cc479ac8696110cb0a2d33f8f2b7d29
======
jrv
Linus actually commented on this lack of identity handling in 2012 in his
famous explanation of why he doesn't use GitHub:
[https://github.com/torvalds/linux/pull/17](https://github.com/torvalds/linux/pull/17)

"since github identities are random, I expect the pull request to be a signed
tag, so that I can verify the identity of the person in question."

And:

"github throws away all the relevant information, like having even a valid
email address for the person asking me to pull."

~~~
ultramancool
Yeah, the GPG signing support in Git would be the best solution to this,
unfortunately GitHub doesn't offer integration for that.

~~~
akshatpradhan
Maybe this is where Keybase.io could come in?

------
seba_dos1
Kinda hard to not come up with it when setting up your credentials is the
first thing git wants you to do before you can commit anything. BTW. You can
also overwrite them by command line switches per commit instead of setting
environment variables.

I guess it's worth noting here that you can sign your commits with GPG:
[https://git-scm.com/book/tr/v2/Git-Tools-Signing-Your-Work](https://git-
scm.com/book/tr/v2/Git-Tools-Signing-Your-Work)

~~~
SilasX
Similarly, nothing stops you altering the time claimed in the commit. Or --
for that matter -- from taking someone's diff and claiming credit for it.

For that reason, I jokingly created `git-upstage`, which streamlines the
process of abusing commit edits and plagiarizing code! It squashes a branch,
backdates it 5 minutes, and claims you wrote it.

[https://github.com/SilasX/git-upstage](https://github.com/SilasX/git-upstage)

Edit: Looks like my last commit left the important stuff commented out and
can't fix it at the moment. Ah well, you're going to use the tool to rip it
off anyway ;-)

~~~
ultramancool
I love this. Had a project in college that was supposed to be time limited...
based on repository times. Oops. Big mistake prof. We rolled back the times on
our repo and laughed maniacally about our free 6 hour extension.

~~~
WalterBright
Should professors really be spending their time locking down all the ways
students may try to cheat? At Caltech, proctoring exams (for example) is not
allowed by institute policy. A student's honor that he didn't cheat is
considered good enough.

~~~
tgb
Why wouldn't you proctor exams? The time spent is small, less than 10 hours a
semester, and the proctors can answer student questions or make corrections
and clarifications to test questions. That it's a small disincentive to cheat
is nice too, though in my experience only the most blatant of cheating would
be caught. I say all this as someone who proctors exams.

~~~
dragonwriter
> Why wouldn't you proctor exams? The time spent is small, less than 10 hours
> a semester, and the proctors can answer student questions or make
> corrections and clarifications to test questions.

Because Caltech faculty (and, for undergraduate student exams, grad students)
have better things to do with their time than proctor exams (and, perhaps more
to the point, because Caltech wants to attract faculty and grad students that
_feel_ that they have better uses for their time that baby-sitting exams.)

And, frankly, like many aspects of the trust extended to Caltech students, its
a recruitment policy -- Caltech is an extremely selective, extremely small
school that is competing with other elite institutions to attract the best
students.

~~~
maxerickson
Honor codes and not proctoring exams (rather, the students doing it
themselves) are a fairly common feature of engineering colleges, it isn't
really something that contributes to Caltech standing out.

~~~
dragonwriter
> Honor codes and not proctoring exams (rather, the students doing it
> themselves) are a fairly common feature of engineering colleges, it isn't
> really something that contributes to Caltech standing out.

> Honor codes and not proctoring exams (rather, the students doing it
> themselves) are a fairly common feature of engineering colleges, it isn't
> really something that contributes to Caltech standing out.

I'm not saying Caltech is _unique_ in doing that, I'm saying that in the
universe Caltech operates in it would conflict with their recruiting interests
-- both for faculty and students -- to operate in a different way.

------
aikah
It's a github 'social' issue , not really a git issue. It might also be a
legal issue (identity theft). And i'm a bit surprised github let people
impersonate others through their 'social' features.

~~~
yxhuvud
It is really not possible for github to track the origin of commits.

For example, consider a fork. If you pull some commits from the original and
then push them to your fork then that would look just like this.

The only thing I can think of is that it may be possible to track commits if
everyone would sign them as they were created, but that would require all
users to change, so I don't see how that can happen.

~~~
jerf
A checkbox that requires push commits to be signed (you don't have to sign
each one, but the top level of any push would have to be signed) would be
nice. So would _any_ indication that commits are signed in the GitHub UI. I've
started signing my commits to GitHub, but verifying even that a signature is
present (let alone correct) requires you to clone the repo and investigate it
with commands you'd probably have to Google, as far as I know. No UI
visibility whatsoever.

------
mmcclure
TBH we "exploit" this when accepting PRs for an open source project I work on.
It's not really feasible for us to expect / force each PR author to have a
clean commit history, so we basically do some squashing, then commit the
"single" change as the original author before merging.

~~~
johannes1234321
So, when submitting to your project it can happen that I'm afterwards blamed
for things I didn't do? (Or praised)

~~~
igorgue
That's the problem with all these guys obsessed with clean commit history.

~~~
ionforce
What's wrong with having a clean commit history?

I think it's something people take too lightly.

~~~
seba_dos1
Nothing. Just like there's nothing wrong with not having it clean.

~~~
bronson
Depends on the project. If I ran the Linux kernel, I'd insist on clear commits
too.

~~~
Pharaoh2
Oh no no no. If you are handling something as important as the Linux kernel,
you will absolutely want traceability over anything as trivial as clean
history. You will impose signed commits and signed merges only... none of
these FF stuff. If you want clean history on top of that, you will enforce
that on original pull request not after the fact.

~~~
bronson
I'm responding to, "there's nothing wrong with not having it clean."

Yes, there often is. And I do enforce it on the original pull request.

------
Argorak
The issue at hand here is interesting: GIT _commit_ integrity is not
guaranteed over all operations, even if you sign commits.

The problem is that GIT often changes commit details. If you, for example,
rebase or cherry-pick a commit, the identity changes - as the commit includes
a reference to the parent commit(s). This means that once you do any of those
(standard) operations, the signature becomes invalid.

Signing only makes sense on a tag level or in repositories that keep all
commits and never change them (e.g. by explicitly merging and adding merge
commits).

There are systems that preserve commit integrity during all of those
operations, e.g. DARCS.

~~~
pornel
IMHO git does it right. If signature was only at the commit level you could do
a variant of replay attack.

For example you could cherry-pick all commits except security fixes and create
a malicious version of the software that has all commits still signed by the
original author.

~~~
Argorak
I was not saying that the signature is _just_ at a commit level ("patches"
being the DARCS lingo).

DARCS, just as git, has tags for that. A tag depends on all previous patches,
so a signed tag guarantees just the same as a signed git tag does.

In that regard, git is strictly less powerful.

------
davorak
You can use github's api to identify out who pushed a commit:

Currently the event in question is on page 3 so you can use:
[https://api.github.com/repos/amoffat/masquerade/events?page=...](https://api.github.com/repos/amoffat/masquerade/events?page=3)

It i will roll to further pages as new events come in.

Github comment with formatted json event output:
[https://github.com/amoffat/masquerade/commit/9b0562595cc479a...](https://github.com/amoffat/masquerade/commit/9b0562595cc479ac8696110cb0a2d33f8f2b7d29#commitcomment-12528903)

The login of the push is identified of course as the owner of the repo
'amoffat'

------
vruiz
Yeah this is known, and you can get yourself an awesome list of contributors
if you want:
[https://github.com/zixan/uberfareestimator/graphs/contributo...](https://github.com/zixan/uberfareestimator/graphs/contributors)

I think github should allow me as a user to confirm contributions made out of
the system, at least the first time per repo.

~~~
smt88
That's a great solution. People should tweet it at Github and see if they
implement it.

------
andmarios
Also you may send email from any address you want if you put it in the “MAIL
FROM” SMTP transaction.

Thankfully the Linux kernel project accepts only signed commits.

~~~
teraflop
> Thankfully the Linux kernel project accepts only signed commits.

This is false, FWIW.

~~~
jordigh
Well, the signoff line that Linux requires is a legal signature, not a
cryptographic one. It is meaningless to us, but it's good enough for lawyers.

------
wcummings
I think this is pretty well known. You could always sign your commits if
you're really worried about someone sticking your email address in their git
config.

~~~
rabbyte
While it's probably well known from a command line perspective, I doubt it's
well known from a web service (GitHub) perspective. I have a healthy distrust
of git logs but trusting a photo and username on GitHub is a pattern
reinforced by every other social app.

~~~
berdario
Not only it's not well known, but it breaks them:

some years ago I reported this issue on gitorious, which yielded an HTTP500
when the repository contained a signed commit:

[https://issues.gitorious.org/issues/193](https://issues.gitorious.org/issues/193)
(it's now down, but hopefully it'll reappear on archive.org)

and it'll prevent Launchpad from automatically mirroring git repositories
(which is paramount to be able to automatically update PPA with recipes)

[https://bugs.launchpad.net/bzr-
git/+bug/1372149](https://bugs.launchpad.net/bzr-git/+bug/1372149)

------
ppierald
I can imagine a scenario where a malicious employee is intentionally injecting
malicious code (backdoor, whatever) and wants that commit tied back to someone
else (their enemy, boss).

~~~
ikeboy
If they have push access, would github log who actually pushed it (i.e. ssh
key)?

~~~
rectang
Yes, Github's authenticated push logs will tell you that. However, Github
won't make those public, because they consider user identification private
info.

(Or at least they won't provide those push logs to the Apache Software
Foundation, which is how I know this.)

~~~
ikeboy
They won't even give it to the owner of the repo in question?

~~~
rectang
They will not. For instance, the ASF cannot get the push logs for all the
repositories under <[https://github.com/apache>](https://github.com/apache>).

------
arihant
So this is a Github feature, which might be useful in some cases, I get that.
The good news here is that it only goes one level deep, i.e., it does not
automagically show up on Linus' account in any way.

This also has been an issue with Git for a long time. In any repository, you
can see the email of the person who committed it, and it can be spoofed,
because there are no checks. So while here we see it linked to Linus' account,
the problem with plausible identity theft has always been a part of Git.

There are ways to solve it. Git can just put "<unsigned>" next to non PGP
commits. Github can also put "<unverified>" when commits are made outside of
Github realm (not using their keys of https auth), or are unsigned.

Just be careful while merging pull requests, which one has to anyway. And
because one has to, these issues never seem to get a fix.

------
logicallee
I don't get it, I never really looked at github comments before. Why are these
comments so low-quality? Aren't developers who commit to github the only
readership?

~~~
wyldfire
I had a relatively sane comment (IMO) about whether github should instead
consider allowing users to opt-in to "show unsigned commits which claim to be
from this address as unknown."

Oddly enough my comment itself was altered to be a mindless obnoxious comment!
(does github use git commits to track the comments themselves?)

~~~
hk__2
Repository authors can edit anyone’s comment.

------
jotux
You can just use this and not have to overwrite your name/email:

    
    
        git commit -m "message" --author=<author>
    

You can even pass a different commit date with --date=<date>.

It's actually a really useful feature when you're migrating a project from a
different SCM system to git.

------
brillenfux
Another example of why email addresses cannot serve as "identities" like so
many people, somehow magically, assume.

If you know it, everything about email and its protocols would make you assume
the exact opposite.

Now PGP signatures on the other hand … but hey, nobody wants those, right?!
Far too complicated! /rant

~~~
nolok
This has nothing to do with emails serving as identities and everything to do
with not believing user's input without verification.

If github was linking to user's profile based on first/last name rather than
email the issue would be the exact same.

------
moron4hire
There is a _huge_ UX problem with validating the legitimacy of anything
online. I have to know that credentials are available, and I have to know that
it's possible to validate them. How do I even know if a particular set of
credentials are legit? I'd have to know where to find validation for them.
That's a whole other ball of wax in itself.

And we default to not requiring such authentication because the means we have
are either completely useless (i.e. passwords) or so onerous (I always have to
Google when I setup cryptographic credentials on anything, and we expect lay
users to do this?) that they ruin adoption rates for software and services.

State-of-the-art secure credentialing should be as easy as passwords. Easier,
even. Yet they're currently as "easy" as configuring Apache.

~~~
cbd1984
Any information you can get online or over the phone can be forged. (Passwords
can be discovered, as can private keys, fingerprints, and the results of
genetic tests.) Certain kinds of physical evidence, such as dead skin cells
with usable genetic material in them, are to my knowledge effectively
impossible to forge, but they can be "accidentally" contaminated beyond
usability. Doing things in-person face-to-face is only an improvement if you
knew the person before anyone had any incentive to fool you on the person's
identity, which is hard; even then, allegiances can be bought, sold, and
changed for other reasons.

My point is that fixing this issue is out-of-scope for a DVCS. It could,
however, be improved a bit.

------
thedoctor79
So it seems the author has identified a real issue here, but I will go meta on
this and identify issues with his demonstration. In my organization this would
count as a bug report, so I wondered why this issue was not communicated
privately to the operators of Github so they can have a chance to fix it
before some un-educated person does some damage. Then I realized this issue
might affect other git content hosters, so going public might alert them as
well as forcing Github to fix it. Regardless, would the best approach not be
to communicate privately first and allow Github to fix it before going public?
If this was raised privately and not acted upon, then why are Github's
internal processes so slow? So many questions, so little time...

~~~
facetube
I reported this to Github privately about a year ago – specifically, I asked
why there isn't some visual indication when Git's `user.email` fails to match
any of the Github account's verified e-mail addresses. If you commit with a
`user.email` that doesn't match _anyone_, you get a little question mark; it
seemed like they could do a similar thing when you commit using a `user.email`
that matches someone-who-isn't-you. Even just showing which Github user made
the HTTP or SSH connection to push the changeset would be an improvement.

The tech told me that the current behavior was by design, and then pretty much
said I didn't know how git worked and didn't understand Github's
team/sharing/trust philosophy. I was pretty disappointed by their response,
all told.

------
2bluesc
It's pretty much the same as forging email. Most won't notice. Both can be
signed with pgp, but few check and it's clumsy for the mainstream.

------
_wmd
In other words, a lot of people haven't the slightest clue how Git works.
Luckily Github record push history separately

~~~
icebraining
This is not just about Git, it's also that Github is implicitly trusting user
data, by linking to the user profile.

In Git, it's clear that there's no authentication, a user is just a tuple of
strings, but on Github the same doesn't apply, a user is actually a well
defined entity which is secured by one or even two factors of authentication,
so the expectations are different.

------
bnrubin
I found that github's automatic identity resolution is actually helpful in
some cases. I migrated a bzr repo into github recently and was pleasantly
surprised to see my contributors matched up to their github accounts. I
understand that many people might not want this, but it is a feature that can
be useful.

------
jayhuang
This has been around for quite a while now; I made a post on my blog about it
back in 2013: [http://www.jayhuang.org/blog/pushing-code-to-github-as-
linus...](http://www.jayhuang.org/blog/pushing-code-to-github-as-linus-
torvalds/)

Of course this doesn't actually give you access to the person's account, but
UX wise, it's incredibly misleading for someone to click a commit in my
repository by "torvalds" and have it actually go to his profile. My issue is
very much with the social implications of this as opposed to it being an
actual security issue (see: signed commits).

There should be some indication at the very least that a commit is not signed.

------
zeeshanm
So, this actually works:

[https://github.com/zixan/uberfareestimator/commit/b4c5a16408...](https://github.com/zixan/uberfareestimator/commit/b4c5a16408d906b06310c6b232bbd947aca1226f)

~~~
seba_dos1
Why wouldn't it? I'd say it's "supported by design".

~~~
zeeshanm
It was a test to test the design.

------
haddr
Unfortunately so far the same is possible for gitlab too.

Isn't it the general problem that each user is authenticated as the "git" user
and the rest (all the git commands) is just "user.name" and "user.email"
fields in prefs?

~~~
mordocai
They could identify users by their auth and store that data with the commits
instead of relying on the user email. You either have to provide
username/password, API token, or ssh key to push to a github repo. All of
these identify you as you.

Edit: It is important to note that this would not replace git authorship info
as it is very possible that you pushed something that someone else committed.
It would allow you to have a UI trail to who pushed it which could help if you
theorize that someone is impersonating someone else.

------
nathancahill
Interesting, there must be some level of validation because it does not show
up in his public activity feed[0]

[0]
[https://github.com/torvalds?tab=activity](https://github.com/torvalds?tab=activity)

~~~
kachnuv_ocasek
That's because there's a difference between a GitHub account (usually
authenticated by a key) and a git commiter (only identified by the name and
email). It would be pretty annoying if hundreds of commits popped up in his
feed every time somebody forked Linux or git.

------
beefsack
GitHub issues become ridiculous places full of mindless stupidity whenever an
issue breeches a certain level of popularity. I'd love to see a mechanism to
improve signal to noise ratios, it's not a place for Redditisms.

------
Aardwolf
I don't like github's dependency on some git EMAIL variables and stuff.

First of all already of course there is the problem that putting your email on
the internet is asking for spam.

But a bigger problem is, if I'm on a machine that doesn't happen to have those
variables configered, and I push something to github, even if I use my github
username and password then, it does not show me as author. Very annoying.

EDIT: I don't like git itself's email dependency either. But at least github
could have done something with the fact that you login with a username... :)

~~~
to3m
You can put anything you like in the email field. I use fake addresses such as
tom@tmbp (me on my laptop), tom@tw7 (me on my Windows 7 PC), and so on.

Add these addresses to your email addresses list on the settings page of your
github account if you want your github avatar, etc., to be shown against
commits using these addresses.

------
latortuga
One workaround would be to remove any public email address you commit under
from your Github profile. Github uses these email addresses to tie back to
your user profile so if you don't want commits pointing at your profile, don't
tie email addresses to your profile.

Perhaps some mechanism is called for here for approving tying back to your
user on new repositories or making any repository not owned by you or your
organizations require an explicit opt-in to tie back to your profile.

Edit: This is kind of the equivalent of spoofing the From address in an email.

~~~
brianshaler
My github profile email is different from my git author email. The latter is
even more accessible. Just run git-log on any repository an author has
committed to.

~~~
latortuga
Yes but if you remove that git author email from your list of emails on
Github, any commits done under that email will no longer link back to your
profile.

------
techpeace
Yeah, this is one of those "feature not a bug" things that's been known for
some time. As others have pointed out, sign your commits if this bothers you.
It's even possible to get your fellow open source contributors to sign commits
to your project, as we do with the Metasploit Framework:
[https://github.com/rapid7/metasploit-
framework/wiki/Landing-...](https://github.com/rapid7/metasploit-
framework/wiki/Landing-Pull-Requests)

------
ppierald
Another good article on git-signing: [http://mikegerwitz.com/papers/git-
horror-story](http://mikegerwitz.com/papers/git-horror-story)

~~~
JoachimS
Yes one have to be careful when merging and signing. But otherwise it works
really well.

------
therealmarv
we even do not know if he REALLY did not commit this ;)

------
rectang
To guarantee the origin of the commits in a Git changeset, you need either
PGP-signed commits or the authenticated push logs for a centralized server.

[http://www.sunstarsys.com/essays/git-and-non-
repudiation](http://www.sunstarsys.com/essays/git-and-non-repudiation)

------
Karunamon
If i recall right, it's abuse of this that got the farcical/satirical "c plus
equality" project drummed out of nearly every code hosting site. The name and
email pulls in a Gravatar, the same one probably used on many other sites,
with the result that it amounts to a really convincing forgery.

------
zooko3
[https://github.com/warner/git-lockup](https://github.com/warner/git-lockup)

Makes it so that when you "git pull" it automatically checks a digital with a
certain public key and refuses to apply the patch unless it has a valid
signature.

------
JoachimS
We use signed commits in the Cryptech project and it works really nice. So
much in fact that I now sign all commits for all git repos I work on. It would
be nice if Github displayed the signature though.

------
sandGorgon
git should really make it possible to use openssh/openssl keys for signing -
so that I have one key both to push to github and sign my commits. I know that
they can be converted from one form to another ... but its really
inconvenient, especially on Windows, etc.

The GPG key is designed for a email based collaboration flow - that Linus
uses. But most of us use Github or Bitbucket's UI to collaborate.

Github/Bitbucket should use this key in their UI as well - to show verified
users.

~~~
jleight
I bought a YubiKey[0] a while back and was able to get it to do exactly what
you're talking about--even on Windows, which I use most often. It wasn't
necessarily easy to set up, but it has been working pretty consistently. It
would have probably been easier if I had known more than just the basics of
GPG.

I have since switched to using my YubiKey and GPG for SSH authentication on
pretty much everything, as well as using it to sign my tags in my public git
repositories. I don't think I would want to go back to moving keys between
devices or setting up unique keys on each device now that I've got my YubiKey
set up. Worth the investment, in my opinion.

[0] [https://www.yubico.com/products/yubikey-
hardware/](https://www.yubico.com/products/yubikey-hardware/)

------
hk__2
Related: [http://mikegerwitz.com/papers/git-horror-
story](http://mikegerwitz.com/papers/git-horror-story)

------
darkstar999
Wow the comments there are on par with 4chan.

------
castratikron
Isn't github just a mirror? I doubt serious kernel development happens there.
tl;dr who cares?

~~~
darkstar999
It isn't just about Linux. You can masquerade as _anyone_ on any public
project and cause confusion.

------
comrade1
This is more of a problem with GitHub than git.

Remember, it's not that hard to host your own git repo. There's no need to use
GitHub.

~~~
hk__2
This has nothing to do with GitHub. The commit author field in Git is like the
“From” field of an email; you can put whatever you want in it.

~~~
simoncion
This has everything to do with GitHub.

Git provides mechanisms to sign both commits and tags, and to verify those
signatures. GitHub fails to make use of those mechanisms.

------
vetrom
related: [https://github.com/will](https://github.com/will)

~~~
mahouse
No, not related.

