Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to take credit for someone else's work on GitHub

repography.com

Post reply on HN
Print view View original

141–150 of 185 posts

Re: How to take credit for someone else's work on GitHub

#141

Post by Dylan16807 »

peeters wrote: post #58
i_have_an_idea wrote: post #54

Earlier quoted context omitted.

I can also write on my own web site that my email address is linus@linuxfoundation.org. But I can't send or receive messages from it, so how exactly would I be claiming it? Does GitHub allow you to impersonate Linus via email? No, it does not.

I think you're fixated on the inverse of what this is. Imagine it's a true commit by Linus identified by his email address. This issue is when someone creates a GitHub profile with Linus' email address and by doing so, causes the GitHub UI to ascribe authorship of that commit to your user profile via your GitHub username and a link to your profile.

Also there's no need to imagine because that's what this is. A real commit with a correct email showing the wrong user.

Re: How to take credit for someone else's work on GitHub

#142

Post by inopinatus »

uncomputation wrote: post #3

GitHub’s response is pretty surprising. How can anyone think this is expected? Having to follow Git’s commit message emails makes sense and indeed anybody can use any email they want to make a commit. But then for GitHub to make the connection between (unverified) commit emails and (unverified) GitHub.com accounts is the issue for me. Since they can’t verify the commit email belongs to a GitHub account, why show that…

The response seems a lazy, thoughtless, self-serving cop-out, one that permits a false identity claim and then pushes the entire burden of challenging it back to the primary victim, who may well be unwitting, and where secondary victims (anyone defrauded by believing a false attribution) have no standing at all.

You can file the whole line of thinking - from design to support - under "worst practices" and "things not to emulate in your own product".

When it comes to handling how unverified author identity is presented and cross-reference, Github could stand to do a lot better.

Fortunately, the problem appears confined to Github's web interface; a git show --quiet e83c516 still produces

    Author: Linus Torvalds 
    Date:   Thu Apr 7 15:13:13 2005 -0700
    
    Initial revision of "git", the information manager from hell

Re: How to take credit for someone else's work on GitHub

#143

Post by mannykannot »

np- wrote: post #52
gtirloni wrote: post #41

Earlier quoted context omitted.

> 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 co…

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

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

Re: How to take credit for someone else's work on GitHub

#144

Post by 22c »

skeaker wrote: post #64
anandoza wrote: post #61

Could someone also write bad code and commit it using someone else's email address in the commit message, thus making the commit link to the other person's Github profile? (Sort of the reverse problem -- "giving blame" instead of "taking credit")

Now you're thinking like the author of git-blame-someone-else: https://github.com/jayphelps/git-blame-someone-else

IIRC there was an infamous (at the time) user hostile commit made to a Google product (Android or Chrome perhaps) where the author was obfuscated to something like "Android Dev" instead of an actual individual.

Re: How to take credit for someone else's work on GitHub

#145

Post by cortesoft »

gtirloni wrote: post #41
nynyny7 wrote: post #7

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…

> 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 co…

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.

Re: How to take credit for someone else's work on GitHub

#146

Post by allset_ »

jeroenhd wrote: post #139
kazinator wrote: post #76

In spite of GitHub's claims that nothing wrong, something is wrong and fixable. GitHub should be showing the identity pulled from the e-mail address, and not replacing it with the name of an associated GitHub account. Just like it does when there is no associated GH account. A reasonable compromise would be to show that name, but turn it into a link to the account if there is one. Then only someone curious clicking o…

That wouldn't work, for example, when you're pushing commits someone else did in another repository. Git is decentralized, so you end up pushing a lot of code that you didn't commit if you use it the way it was intended. The solution, in my opinion, is to show a great big warning or error icon next to the name of every unverified commit, and to every unverified push as well. Developers and version control managers ca…

GitHub already has this, called Verified Mode [1]. It has to be opted into rather than out of though.

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

Re: How to take credit for someone else's work on GitHub

#147

Post by rezonant »

Gigachad wrote: post #96
np- wrote: post #52

Earlier quoted context omitted.

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

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"

Re: How to take credit for someone else's work on GitHub

#148

Post by rezonant »

charcircuit wrote: post #98
np- wrote: post #52

Earlier quoted context omitted.

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

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.

Re: How to take credit for someone else's work on GitHub

#150

Post by DyslexicAtheist »

nynyny7 wrote: post #7

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…

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

Post reply on HN