4 ms·

> 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

by 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.
  - kreetx 5y ago
    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.
  - kelnos 5y ago
    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.
    - jodrellblank 5y ago
      > "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.
      - Dylan16807 5y ago
        > 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"
Gigachad 5y ago
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.
- rezonant 5y ago
  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"
charcircuit 5y ago
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.
- rezonant 5y ago
  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.
mannykannot 5y ago
> 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.

by np- 5y ago

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.
- kreetx 5y ago
  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.
- kelnos 5y ago
  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.
  - jodrellblank 5y ago
    > "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.
    - Dylan16807 5y ago
      > 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"

Gigachad 5y ago

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.

rezonant 5y ago
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"

charcircuit 5y ago

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.

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

mannykannot 5y ago

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