Hacker News Reader

Comment by gtirloni | Hacker News Reader

> Still they want the commits to be associated with their current GitHub account

Well, tough luck? I don't think it's that important. Just accept it as a fact of life: you lost access to your email account and can't verify you still own it (you don't, clearly).

GitHub should just show the e-mail address when it can't associate that to an account, maybe show it's unverified and link to a help page explaining anyone could have faked that in the commit. I don't understand why they care so much to put a face (the GH account) on the commit when the address is not verified.

View on HN

> Well, tough luck? I don't think it's that important. Just accept it as a fact of life: you lost access to your email account and can't verify you still own it (you don't, clearly).

This case might not be super important in the long run, but why does it have to be a fact of life? If a system doesn't work as its human operators intend, that's a system failure, not a human being failure.

> This case might not be super important in the long run, but why does it have to be a fact of life?

For the very reason mentioned in this article: people can claim the commits without verification.

Why doesn't the fact of life go the other way?

"people can claim the commits without verification." - Well, tough luck? I don't think it's that important. Just accept it as a fact of life. You didn't cryptographically sign your commit and now nobody (including you) can prove who made it.

I think the issue is that this isn't a "fact of life", so github could either show the original email or pull in the account with a verified email. What it does now appears to be a bug.

The distinction is in where the potential harm can be.

With the current status quo (unverified email addresses can "steal" commits), you create confusion in the general developer community. Anyone who looks at those mis-attributed commits will be confused, and possibly misled.

If GH didn't associate commits unless the email address was verified, then, yes, some people wouldn't get "bragging rights", but the harm would be limited to that person. Others who look at those commits would still see the correct person's name, even though it wouldn't be associated with a particular GH account.

> "Others who look at those commits would still see the correct person's name,"

They would see the name which was written into the commit; assuming that's "the correct person" is the same mistake. Associating to the GitHub verified email account is incorrect in the same fashion, but going the other way. They're both only text saying "Linus Torvalds", in the absence of signing, neither is more or less authoritative than the other. Connecting it to a random profile looks wrong, but trying to correct it to the 'right' profile lends it an air of legitimacy it shouldn't have.

Papering over that is like teaching people to click through warning messages, or that HTTP is fine because the site shows the right looking text.

> Papering over that is like teaching people to click through warning messages, or that HTTP is fine because the site shows the right looking text.

That's a completely separate problem, and whether it is papered over is completely independent of this problem.

With this problem, even if you already verified the repo, even if there are signatures, it still shows the wrong profile.

> Connecting it to a random profile looks wrong, but trying to correct it to the 'right' profile lends it an air of legitimacy it shouldn't have.

Displaying nothing is not "trying to correct it to the 'right' profile"

Because we exist in the real world with real constraints. We have only two options, allow people to stick their name on others commits, or have unverified emails just show plainly.

Neither of these is ideal but at least the second one never tells lies.

This- if the commit is unsigned, then just show what the commit says. Don't "enhance" the commit in an even more insecure way than the "original sin"

You could add humans into the verification process. I imagine the number of people who want to associate old emails they don't have access to with accounts to be small. If you could prove that you owned the account via other means it could be manually added to your profile.

Exactly, such as.... by contacting Github support (which they offer as a way to undo the incorrect enhancement on the original commit anyway). I think Github should reverse course on this one.

> If a system doesn't work as its human operators intend, that's a system failure, not a human being failure.

Well, I think we have to consider who was responsible for it not working as its human operators intended (my use of 'who', rather than 'what', in that sentence is not a grammatical error; it is a clue as to the correct answer.)

Unless the outcome described here was one of the explicit goals of the creators of the system, then you cannot assume it was an intended outcome, as opposed to an unintended consequence of what they chose to do. If it was the latter, then "that's what it will do" is not a justification for what it does do; if it was the former, then it was just a bad choice. The only way to justify the situation is if there was no alternative that was not strictly worse, and if so, then it should be made clear that it is so.

Bitbucket allows the repository administrator to set up a mapping of email address to user. I think this is a nice middle ground.

I guess they can also say tough luck to you, because they don’t think preventing people from posting old commits that are credited to an unverified email is that important. Just accept that we don’t verify it as a fact of life; you can’t be sure of commit ownership.

What do you mean tough luck? The system works exactly like he said. It’s tough luck for people who want it to work differently.

Maybe github should use gravatar if the email doesn't match a github account. Not that that helps with old email address you no longer control but it does let you add an image to an arbitrary email you do control, separate from github.

Reply on news.ycombinator.com