Because that's git's underlying mechanisms in action. In a distributed system, there's no centralized database to check things against, so there's no (distributed) way to do verification, leading to the issue described here. With the use of public key cryptography, there's a disconnected way to authenticate commit, and it works as well as public key cryptography does, but GitHub has all the levers needed to moved the needle, with `hub` and them holding public keys for registered users.
Really? In this case isn't it just the Github web service that makes a decision on what to display?
Sure if you clone the git repo you get the e-mail address, but then you also won't get any information about who the email belongs to on Github.
I don't see how the design of Git affects this issue. This is simply one if clause away from being solved in Githubs frontend source code. Just check if email.verified: display the user, else, don't do that.
In the else-case all you'd get is a situation where one unknown user has Linus e-mail in their list of e-mail addresses, in Githubs DB, and a bunch of git commit logs with the same e-mail. No one would ever make the connection from the commit log to the list of Emails in the DB. Because the e-mail hasn't been verified. It's as simple as that to me but I could be wrong.
Github could easily add its own handling for historical addresses of well-known developers, and block others from masquerading as them, once abuses like this are reported.
One rule for famous developers, another for all the rest of us. Completely backwards because everyone knows Linus made Git so that's no threat to him, but someone retro-claiming authorship of normal person's work is much worse because nobody knows differently. Also expecting Github support people to mediate "he said/she said" arguments about who made what commits, or owned what email address that many years ago.
There are some kinds of attacks that are more likely to be launched against well known people. But even for lesser-known developers their names with corresponding addresses will appear in the archives of mailing lists, and this could be used to correct the record.
But if there's no record of someone at all then there isn't an easy way to detect this kind of abuse.
> Because that's git's underlying mechanisms in action.
no? git just has an email field on the commit. it's github that has decided to allow people to associate unverified emails with their accounts, and also display this association whereever the email is listed in a commit.
