7 ms·

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 pr

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.

odyssey7 5y ago
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.
baobabKoodaa 5y ago
> 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.
- giancarlostoro 5y ago
  Does this redo all the commit hashes?
  - nynyny7 5y ago
    Yes, as it is rewriting history. And that would be a massively bad idea.
    - giancarlostoro 5y ago
      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.
  - progval 5y ago
    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.
    - Cthulhu_ 5y ago
      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?
arraypad 5y ago
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 https://git-scm.com/docs/gitmailmap
- nynyny7 5y ago
  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.
  - Kwpolska 5y ago
    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 https://github.com/settings/emails
  - trulyme 5y ago
    Well, yes, but maybe they should? It doesn't seem like a huge feature...
    - angus-g 5y ago
      What about if somebody clones a repo, then adds a .mailmap pointing all the addresses in the history to their own?
      - trulyme 5y ago
        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.
      - teawrecks 5y ago
        Then in their clone, they made all the commits. But who cares about their clone?
gtirloni 5y ago
> 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.
- greggman3 5y ago
  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.
- np- 5y ago
  > 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.
  - d23 5y ago
    > 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.
    - jodrellblank 5y ago
      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.
nixpulvis 5y ago
What do you want; official Git identities? Sanctioned by Linus himself? Or would you rather log into Xbox Live?
deleted 5y ago
[deleted]
res0nat0r 5y ago
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-signature-verification/signing-commits https://docs.github.com/en/authentication/managing-commit-si... https://www.devopsauthority.tech/2020/07/18/github-getting-started-with-gpg-signed-commits/ https://www.devopsauthority.tech/2020/07/18/github-getting-s...
- DyslexicAtheist 5y ago
  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
  - tremon 5y ago
    Security requirements are often at odds with good UE.
  - res0nat0r 5y ago
    There's no way around it, because git commits by default can be forged due to the way it was designed.
DyslexicAtheist 5y ago
> 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.
Cthulhu_ 5y ago
> 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.
worldsayshi 5y ago
You could just flair the username as unverified and have the flair link to an explanation.
agilob 5y ago
>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/jayphelps/git-blame-someone-else https://github.com/SilasX/git-upstage https://github.com/SilasX/git-upstage
- Master_Odin 5y ago
  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.

odyssey7 5y ago

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.

baobabKoodaa 5y ago

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

giancarlostoro 5y ago
Does this redo all the commit hashes?
- nynyny7 5y ago
  Yes, as it is rewriting history. And that would be a massively bad idea.
  - giancarlostoro 5y ago
    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.
- progval 5y ago
  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.
  - Cthulhu_ 5y ago
    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?

arraypad 5y ago

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 https://git-scm.com/docs/gitmailmap

nynyny7 5y ago
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.
- Kwpolska 5y ago
  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 https://github.com/settings/emails
- trulyme 5y ago
  Well, yes, but maybe they should? It doesn't seem like a huge feature...
  - angus-g 5y ago
    What about if somebody clones a repo, then adds a .mailmap pointing all the addresses in the history to their own?
    - trulyme 5y ago
      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.
    - teawrecks 5y ago
      Then in their clone, they made all the commits. But who cares about their clone?

gtirloni 5y ago

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

greggman3 5y ago
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.
np- 5y ago
> 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.
- d23 5y ago
  > 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.
  - jodrellblank 5y ago
    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.

nixpulvis 5y ago

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

deleted 5y ago

[deleted]

res0nat0r 5y ago

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-signature-verification/signing-commits https://docs.github.com/en/authentication/managing-commit-si... https://www.devopsauthority.tech/2020/07/18/github-getting-started-with-gpg-signed-commits/ https://www.devopsauthority.tech/2020/07/18/github-getting-s...

DyslexicAtheist 5y ago
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
- tremon 5y ago
  Security requirements are often at odds with good UE.
- res0nat0r 5y ago
  There's no way around it, because git commits by default can be forged due to the way it was designed.

DyslexicAtheist 5y ago

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

Cthulhu_ 5y ago

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

worldsayshi 5y ago

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

agilob 5y ago

>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/jayphelps/git-blame-someone-else https://github.com/SilasX/git-upstage https://github.com/SilasX/git-upstage

Master_Odin 5y ago
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.