Hacker News Reader

Comment by nynyny7 | Hacker News Reader

I do see a point in it working like it does, though. I'm one of the lead developers on a free software project with over 20 years of history. Even though the project has used multiple version control systems (and hosting providers) over time, we have imported our entire project's history going back to the very first commit into git and GitHub.

Not every contributor has kept their email address for over 20 years. Some don't have access to the old addresses they once used for commits. Still they want the commits to be associated with their current GitHub account; even if it's just for statistics and "bragging rights".

If GitHub required email address verification, how would this be done?

EDIT: To be clear: With "working like it does" I'm referring to the possibility to add unverified email addresses to your account and have commits attributed to you.

View on HN

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

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

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.

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.

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.

In this case I think you could use a .mailmap [1] in the repo to associate the old email addresses with current, verified addresses.

[1] https://git-scm.com/docs/gitmailmap

Interesting. One never stops learning new git features...

However, while this works for git (i.e., maps old address to new address in "git log" for example), GitHub does not seem to honor this file.

GitHub bases the association of commits to user accounts on the list of e-mail addresses configured in the user’s profile: https://github.com/settings/emails

Well, yes, but maybe they should? It doesn't seem like a huge feature...

What about if somebody clones a repo, then adds a .mailmap pointing all the addresses in the history to their own?

If somebody clones the repo they can even rewrite history. But that is not the same as them being able to claim the ownership of a commit in the original repo.

Then in their clone, they made all the commits. But who cares about their clone?

Now which commit's mailmap file should be used for the association? Whatever is on the "default" branch currently?

Whatever is in the branch you are looking at? Seems fairly straightforward.

Viewing a specific commit or viewing the repositories' statistics ("insights" tab) both have no attached branch.

in Github or in Git itself? While possible, I don't believe there's many floating commits around.

The other issue of course is that at this point in time, there would not be a .mailmap. Of course, github can then fall back to a .mailmap file in the latest commit of the main branch.

Commits are not usually floating but are very commonly in more than one branch.

> I do see a point in it working like it does, though

really? I'd think a product whose _primary_ value proposition is "integrity and assurance over what was committed when by who" this is such an odd edge case github refuses to fix. If their security team isn't looking at this and thinking "oh my these aren't the secure-by-design defaults we should have", fire them.

To say "oh but you ought to use cryptographic keys to allow attribution", then why not a color code, or a subtle warning, whatever ... to hint at the fact that attribution in this case isn't only weak but totally impossibly (instead of pointing to a user-id that is 100% wrong and saying "yupp, that's the one who we believe did the commit").

Not exactly great UE. Also terrible for supply chain security. The whole thing is hard to explain because it wasn't that UE was chosen over security. There is no logic to why it was half-arsed like this and they actually get away with it all while grand-standing about all the things they do for "security".

All Github-security brings to the world (other than hype) is:

- Cockpit: which allows me to produce security vulns in an automated manner, and

- the GHSA vulnerability severity scoring which essentially labels anything that has CVSS3 critical as moderate and allows downplaying of the real score.

As a Microsoft company perhaps this is just what it is and I'm to blame for expecting things to make sense.

> Still they want the commits to be associated with their current GitHub account; even if it's just for statistics and "bragging rights".

> If GitHub required email address verification, how would this be done?

If it can't be done securely - e.g. you verify you own the e-mail address - it shouldn't be done, IMO. It's like losing your 2FA token and all recovery methods; for the sake of security, you should consider that account lost. Because if you can get it back through other means, then a scammer / impostor can do so as well.

At some point you just have to give up. Anyway in the case of e-mail addresses, ideally you have your real name in the address itself for anything formal / work related.

Alternatively, what GitHub could do is mark these accounts as unverified. It would also mean they should allow multiple user accounts to be associated with a commit's e-mail address though.

And finally, some manual work might be involved. I'm sure there would be ways and means to get verified on github (like on twitter), and somehow claim that e-mail address in a more formalized fashion - and to dispute it. In the case of Linux and Go, it's obvious and well-known who the original authors / committers are, so a bit of manual work to associate those commits to a GH account shouldn't be too much of an issue.

One idea: just show the statistics of unverified commits, demarcated as such, in the user’s profile. This is a more transparent variation on the current behavior.

>If GitHub required email address verification, how would this be done?

author data in a commit can be replaced by repository owners. You can replace all old email addresses to new ones https://github.com/jayphelps/git-blame-someone-else https://github.com/SilasX/git-upstage

Doesn't changing the author affect the commit sha? If so, doing this would cause some amount of pain with syncing all copies of the repo, branches, etc, making it a non-starter I think.

You could just flair the username as unverified and have the flair link to an explanation.

If everyone is concerned about commit identity hijacking, you can configure your repo settings to reject any commits which aren't GPG signed.

https://docs.github.com/en/authentication/managing-commit-si...

https://www.devopsauthority.tech/2020/07/18/github-getting-s...

that's great but it requires an active step on behalf of the user which is violating secure defaults principle. it also violates the principle of good UE

Security requirements are often at odds with good UE.

There's no way around it, because git commits by default can be forged due to the way it was designed.

> If GitHub required email address verification, how would this be done?

You could just run a script which rewrites the email address in all the git commits, and force-push the revised version.

Does this redo all the commit hashes?

Yes, as it is rewriting history. And that would be a massively bad idea.

Thank you, wanted to know, if so, this should really be noted when suggesting these sort of things since it has unaccounted consequences especially when you consider most people use git but don't necessarily know how to use it beyond the basics.

Given that GGP's use case is:

> we have imported our entire project's history going back to the very first commit into git

Then it isn't a problem. Just change the email addresses while importing.

But what if you don't think of it at the time?

Or what if you don't actually want to change the e-mail addresses because they are important historic data? or part of a commit's signature?

What do you want; official Git identities? Sanctioned by Linus himself? Or would you rather log into Xbox Live?

Reply on news.ycombinator.com