It is not merely for the first commit, here, the first commits are used as a proof of concept since they are large repostories known to everyone. You can try it yourself, by changing your email to something like Linus' email in your git config, and then trying to commit code. GitHub will automatically show Linus' profile.
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 as though it were true?
And if "the proper way to verify committer identity is, as per GitHub's response, a cryptographic signature", Github is certainly not pushing this.
If the only real security around attribution is "a cryptographic signature", GitHub could do a lot better in pushing this, making it essential part of the signup or "getting started" and such.
Because that's git's underlying mechanisms in action. In a distributed system, there's no centralized database to check things against, so there's no (distributed) way to do verification, leading to the issue described here. With the use of public key cryptography, there's a disconnected way to authenticate commit, and it works as well as public key cryptography does, but GitHub has all the levers needed to moved the needle, with `hub` and them holding public keys for registered users.
Really? In this case isn't it just the Github web service that makes a decision on what to display?
Sure if you clone the git repo you get the e-mail address, but then you also won't get any information about who the email belongs to on Github.
I don't see how the design of Git affects this issue. This is simply one if clause away from being solved in Githubs frontend source code. Just check if email.verified: display the user, else, don't do that.
In the else-case all you'd get is a situation where one unknown user has Linus e-mail in their list of e-mail addresses, in Githubs DB, and a bunch of git commit logs with the same e-mail. No one would ever make the connection from the commit log to the list of Emails in the DB. Because the e-mail hasn't been verified. It's as simple as that to me but I could be wrong.
Github could easily add its own handling for historical addresses of well-known developers, and block others from masquerading as them, once abuses like this are reported.
One rule for famous developers, another for all the rest of us. Completely backwards because everyone knows Linus made Git so that's no threat to him, but someone retro-claiming authorship of normal person's work is much worse because nobody knows differently. Also expecting Github support people to mediate "he said/she said" arguments about who made what commits, or owned what email address that many years ago.
There are some kinds of attacks that are more likely to be launched against well known people. But even for lesser-known developers their names with corresponding addresses will appear in the archives of mailing lists, and this could be used to correct the record.
But if there's no record of someone at all then there isn't an easy way to detect this kind of abuse.
> Because that's git's underlying mechanisms in action.
no? git just has an email field on the commit. it's github that has decided to allow people to associate unverified emails with their accounts, and also display this association whereever the email is listed in a commit.
What happens if Linus Torvalds has a verified Github account, and I commit to my rudely named project on my local computer with his email address and then push to Github; do they then show the commit with his Github account because his Github email is verified?
Yes, and there are a number of past stunts that include forking the Linux repo, pushing fake/misleading commits, and then showing how Github lets you see those commits in a context that implies they are part of the upstream Linux repo.
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 <torvalds@linux-foundation.org>
Date: Thu Apr 7 15:13:13 2005 -0700
Initial revision of "git", the information manager from hell
1 - Don't associate the commit to an account if the email is unverified, obviously
2 - If someone tries to "forge" ownership by pushing a commit with an e-mail that doesn't belong to the GitHub account being used to push, a "unverified" warning should be added to the commit and manually claimed by the account owning said e-mail for its status to change.
That would break any workflow that has the slightest bit of decentralization, and would only work in a github-first workflow. Suppose two developers are working on a feature that requires two changes. Each developer works on a change in their own development branch. It wouldn't make sense to submit a PR for each change, because they depend on each other to be a complete feature. Therefore, they should merge the two dev branches together, then submit a pull request for that merged development branch to then be merged into the main branch. In your proposed scheme, this would then show up as an attempted forgery, rather than a perfectly normal workflow.
The email field is for humans, who can lie, and shouldn't be used as authoritative by github.
> this would then show up as an attempted forgery, rather than a perfectly normal workflow.
they said unverified, not marked as a forgery
> The email field is for humans, who can lie, and shouldn't be used as authoritative by github.
and your solution is just to have everything marked as unverified, including commits that I push using my credentials and contain an email that I've verified with github.
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.
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.
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.
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
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.
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.
> 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.
"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.
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.
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.
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.
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
> 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.
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.
At some point, we need to start treating Windows like Internet Explorer or Safari. Things break on it all the time, completely unpredictably, and it doesn't support many useful features you'd expect to be used.
We should really just tell Windows users to upgrade to a real operating system, rather than go out of our way to support it.
This is just a fact of how attribution works in Git. It's not GitHub's responsibility to figure out exactly who should be given credit for which commit, they're just a viewer on top of Git commits.
Imagine you did some work at some workplace years ago, and you want credit for it. You don't have access to that email anymore, but you'd still like to have the credit and have it link to your account. That's the usecase.
> It's not GitHub's responsibility to figure out exactly who should be given credit for which commit, they're just a viewer on top of Git commits.
If it's not GitHub's responsibility, then why are they doing it? Nobody forces GitHub to attribute commits to GitHub user accounts. (And yes, you answer this "why" question in your next sentence, I'm just pointing out that your argument is nonsensical.)
Because they're trying to help build a social graph insofar as it helps people do their work, without the aspect of actually taking responsibility for being a source of truth around it.
Sure, I could claim an original Unix dev's work. But what does that actually do, besides raise questions I can't answer at interviews?
I'm extremely surprised as well. This seems like a obvious vector for an impersonation attack. A malicious user could do this, then perhaps they would have more success submitting a malicious change to "correct a flaw in their previous commit"
At the very least, repo owners should have some better control over how attributions display when the user is not a project member or the email used is not verified to an existing user.
Will Github verify a commit associated with a GH account via an unverified e-mail address?
If so then it's probably fine since you would have to demonstrate ownership of an e-mail address that was contained in the signed payload, or you would have to be able to sign payloads yourself (i.e. you have the private key).
How does it verify them? They could ask you to sign a message to prove that you control the private key, but I don't think public Github (or Gitlab) does this. They just assume you hold the private key to any pubkey you upload. Alternatively your private installation could have a centralised trust store of keys.
I thought this might be something different. Have seen this happen multiple times over the years - even once just last week.
Colleague files an issue with a PR. Project owners close it, say 'no, not a bug', then... commits the same thing themselves as "fixed!". Saw this years before in cvs/svn, and... at least in the GH world there's some evidence of the original PR author having done the work in the first place (vs being invisibly cut out).
I had this happen on a small PR I submitted within the past year. I didn’t think anything of it at the time, but your comment led me to glancing through the past PRs and it’s comical how many are closed with a “thanks, I’ve committed an equivalent patch” comment.
One the one hand, it’s his repo and he’s free to do whatever he wants. I actually admire how ruthless the maintainer is on closing issues, must be great for staving off OSS burnout.
On the other hand, I don’t love how antagonistic it is to outside contributors. Litestream[0] is an example of open source-closed contributions, but at least it’s upfront about that in the README. (And the policy has actually changed to open for bug fixes.) I would open an issue/PR on Huey suggesting adding a similar disclaimer, but it’d probably be closed, ha.
In many cases this is the right thing for a maintainer to do: a contributor produces a PR and a proposed patch, but often that patch doesn't solve the whole problem, or clashes with the coding style, or isn't very efficient, so the maintainer does their own fix, because that is faster than getting the contributor to produce a modified version.
it can be, yes. there's chicken and egg issue of trying to help other people be more proficient in making those mods, learning about larger parts of the system, etc.
there's also the issue of being told "no, that's not a bug" or "no, WONTFIX", then... hours or days later... producing the same code patch as your own. Definitely a jerk move.
The polite thing is to fork the contributor's PR branch back into the project repo, make changes preserving history, and then merge or squash merge the result.
Some projects by nature attract high quality PRs. Others, like a game I built, have the unfortunate curse of attracting PRs with such low quality that it's kinda heart-breaking to shut them down.
It's one thing to read a good feature request in a Github issue and build it yourself. It's a whole other thing to modify a low quality PR in a polite way, see what they were trying to do, clean it up, refactor it. It can easily be 5x the work of just doing it from scratch as the project maintainer.
This experience, especially after your hundredth time, can jade you in a way and make you seem rude when you decide it's not worth the courtesy nor charity.
Yeah, I get why this happens. And to be clear, I didn't dig in to the all the PRs and compare them vs the maintainer's commits, so I have no idea of the difference in code quality between the two.
I'm sure it's frustrating when maintaining a fairly popular OSS tool to receive a PR that's 95% of the way there. Having to go back and forth to coach someone on getting that last 5% (or the contributor just dropping the PR then ghosting) vs just doing it yourself, I totally get it.
However from the contributor's point of view, when GH has support for co-authored commits, it comes of as a bit of jerky move when you take the time to submit a PR to not at least get credit via a co-author commit message.
GitHub's "support" for this is the difference between a commit credit and an author credit, which is a mechanism in git that has particular meaning with respect to cherry-picks and rebases. It should be considered awkward to attach someone else as "author" on a commit they might only sort of recognize.
Maybe instead of "taking the time to submit a PR" you should first submit an issue and only work on substantial code changes you are going to become emotionally invested in after you've negotiated the correct path forward with the maintainer? Open source used to be about communication and collaboration, not cowboy coding.
Yes, I do this for my own OSS projects. The standard approach of giving feedback and waiting for the user to fix something is fine, but for a small change it's easier to just expedite the process and do it myself.
But if my version of the code has substantial changes (ie changes beyond just whitespace, small tweaks to the code, changing the commit message), I push it to a branch and ask the PR author to review and approve it first. Only after they approve it do I merge it into master and close the PR.
I also retain the GIT_AUTHOR of the original PR so that they still get credit; my user is only the GIT_COMMITTER. And I add a "Closes #" ref to the GH PR in the commit message so that it can be tracked later. git also has a de-facto standard of having multiple authors for a commit via `Co-authored-by:` lines in the commit message. This is useful for when my contribution is large enough to be equivalent to the PR author's.
Note that this doesn't work for workflows that require signed commits. If you have such a workflow, you have to go back to giving feedback and waiting for the PR author to make changes.
> Note that this doesn't work for workflows that require signed commits. If you have such a workflow, you have to go back to giving feedback and waiting for the PR author to make changes.
While everyone else who uses the project suffers with the bug that was being fixed as they wait for the person who contributed the patch to go through some hazing process involving code formatting that they (hopefully: I realize some people are in it mostly for the GitHub gamification credit of being a "contributor" on their landing page and thereby will do absolutely anything to get exactly and precisely the author credit on the commit) didn't sign up for. No: please for the love of everyone you are responsible for just commit the fix and thank the person later.
Well, I wasn't talking about GH OSS repos specifically in that point. In any case, I imagine that any repo that requires signed commits is also corporate-enough that it'll have a CLA requirement, so if the PR author is unresponsive the maintainer could take the code and commit it as themselves anyway.
I've lately been feeling bad, and thinking I must look like an ungrateful asshat, about closing lower quality PRs (IMHO) with valid bugfixes but which introduces some new, possibly subtle, bug instead. Or having to close abandoned PRs because the submitter gave up before that last polishing to match the standard of my own repo. :(
Now I feel better knowing that I can do that final polish myself, while keeping the submitters original contrib!
No, not cool. If you modify a submitted commit, set the Author field to the original author and add a Signed-off-by field with your email. Then you BOTH appear.
The alternative is way worse: it turns into this culture of forcing people who just tried to help with something minor to suddenly be bullied asking for updates to code they were done with. I gave you a fix. It was a potential fix. It was one of many possible fixes. It is your project, and you should figure out what you actually want to commit. And yet way too often the maintainer spends more time trying to explain to me what they don't like about my patch or what other relevant work needs to be done in order to commit the patch than it would take for them to just do it themselves now that I showed them what to do.
I am following a ton of issues on projects like Flutter and Cargo that are somehow steeped in this culture and it frankly just seems like nothing ever gets fixed. In some cases pull requests are open for years as people bike shed back and forth arguing over some extremely minor point in a patch, letting thousands of other developers suffer waiting for a patch that to them would work exactly the same either way, because of some weird culture that has been built up surrounding "maintainers may only click commit or leave comments while contributors type all of the code", and if the person who made the patch doesn't want to--or simply can't as they grok the requirement--satisfy some procedural process the world now has to wait for someone else to step up and submit themselves to this process with a new pull request, despite the maintainers having clearly all spent hours typing comments nitpicking on what at the end of the day is often literally a 30 line patch they apparently refuse to just re-type themselves.
In some sense I frankly think this is an entitlement issue on both sides: the maintainer isn't entitled to the continued time and effort of the person who submitted the patch--and certainly isn't committed to them doing exactly what the maintainer wants--and nor is the submitter entitled to some weird GitHub-specific contributor "credit" on the maintainer's project and the requisite control over the patch and how it gets applied that getting that would have to imply.
Should the patch submitter get some love? Yes! Is the bug tracker sufficient? Maybe! (I will say for myself this is absolutely sufficient: unless I am fixing some world-shaking bug--which does happen given what J do--the most important thing to me is going to be getting the feature or fix I wanted landed with minimal delay and preferably the least effort from me, not a very specific form of control over a commit.) If not, is having a file somewhere of "helpful people" enough? I want to say "yes", and I'll up it to "certainly" if it includes a mention of why.
But like, I really do think there is something super core going wrong with the open source world here, and this "pull request" model from GitHub with "contributor" status is to blame :/. In addition to the obviously-evil gamification of the codebase (from the badges) I think one reason people get this feeling of entitlement over their patch is that they put way too much work into it before it even gets presented as they go for this completed pull request model. 99.99% of the time what I want as a maintainer isn't someone who spent a month working on a patch that they are now going to argue with me about: I want a single paragraph a month earlier with an explanation of what is needed and maybe I could have solved it in a few hours or explained why the concept won't work or would conflict with planned effort.
On the other side, I then think the UI--combined with this inferred expectation from the patcher--forms that brutal entitlement from many maintainers that they maybe never have to touch code again and can just armchair quarterback / long-range pair program other people into getting some exact result. This is what chases away the quality contributors, as the quality contributors know that reformatting code is easy but p...
> And would I have minded if they didn't put me there? No, and honestly I almost find it weird sometimes that they did... I certainly didn't ask.
Having your name in the credits brings some of your reputation to their project. Having 'name brand' contributors is a benefit all its own for many projects.
I remember this earlier subthread where someone was criticizing GitHub for allowing this (even using Torvald as someone to impersonate!), and others offered some defenses (which were IMHO dubious):
Finally, I thought this phrasing was funny, like commits have a non-substantively transferable ownership, like an NFT (though FYI it's quoting an older discussion of the same problem):
>Someone wrote about the whole situation on Medium in November 2021: "The 1st commit of git/git no longer belongs to Linus Torvalds".
I noticed that arraypad is really trying to push his repography project. Whilst this is not a bad thing, it seems like he is using the blog posts as an excuse to push more his project.
I don't mind that much, but I think I've seen these posts hitting the front page quite a lot already - it's a good strategy but it could be maybe against the guidelines:
> Please don't use HN primarily for promotion. It's ok to post your own stuff occasionally, but the primary use of the site should be for curiosity.
I didn't look at the previous posts you mention, but TFA is what I would consider of interest and curiosity. I didn't find it at all to be self promotion. You have to read to the bottom of the post before you are told what repography is selling.
I'm not entirely sold on the explanation "This is just how git commit (messages) work". GitHub could easily limit linking the GitHub profile to profiles whose e-mail address has been verified (by usual means, no GPG required).
They could show statistics and attribution limited to the data available in the commit messages (e.g. accumulated statistics by e-mail address) for contributors without a GitHub profile.
Am I missing something here?
(Edit: just read the other comments addressing the use cases)
I have used emails in the past I can no longer verify, so I see a use case for linking unverified emails to profiles if there's only one profile claiming the email address
However, if another profile verified that email address, it definitely shouldn't link to another profile that hasn't verified
That isn't fair either though. I can see the ISP I quit using 15 years ago letting someone else have my old email address, but now they can claim to be me.
I don't know how to handle this situation. It is somewhat easy to verify that a commit today comes from an email address I control now. However if I claim an unverified commit from years back is it really me just because I now control that email?
Since [by default] you own the IP for code you commit, this is effectively claiming to steal intellectual property. Also professional credit and fame, which can directly relate to employment opportunities.
This seems to me to be the least important aspect of whatever is happening.
> can directly relate to employment opportunities
Given how free we are in choosing work, it seems to me you could just go work for a workplace that doesn't trawl through your charity history to figure out you're worthy enough. That's a matter of self-respect, which you should absolutely have.
That is the right answer, but it means 15 years ago you need to have done the right thing, and also means not losing the private key (which should have expired) in the mean time.
I think you're missing the point of what the author is asking. Showing the email address from the commit is one thing (and the author is fine with showing that). That's the limit to what git gives you. Associating that email address to a GitHub user profile which never verified ownership of that email address is a GitHub UX decision, having nothing to do with git. That's what the author is saying is a security flaw.
That said, clearly users shouldn't be ascribing any level of certainty to commits that point to a GitHub profile even if the email address is verified, since AFAIK nothing is stopping the inverse attack, i.e. having someone else take credit for your work. Which is arguably more exploitable.
> The problem is that GitHub makes this association even for unverified email addresses. In this case of course it really was Linus who made the first commit, but all it took was someone to add Linus's email address to their GitHub profile - without any verification - and now GitHub displays this person as the author instead.
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.
What happens if multiple github users add the same unverified email address for a particular commit in a repo to their accounts, how does it know which github username to pick to display next to the commit?
An email address can only be associated to a single GitHub account.
If “Alice” adds alice@example.test to their account, GitHub will check if the email is not associated to an existing account, and then proceed to handle the request. Then, when “Bob” tries to add the same email to their account, GitHub prints the following error message “ Error adding alice@example.test: email is already in use.”
In your example, GitHub will display the username of the first user to add the (unverified) email to their account.
I worked on the security team at GitHub, this was a long standing part of how git works. GitHub allows users to verify commits via GPG signatures to prove that they committed something but it doesn't work for proving a negative, that you did not commit something.
We got so many of these submissions which are clearly called out in the rules/scope, usually the people who don't read the rules don't find anything useful. ¯\_(ツ)_/¯
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")
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.
Yes, simply change the email and author before commit and should work.
Note that git already provides a way to mark a commit with someone else authorship, but in that case you remain as the "original author" of the commit, usually shown as "X authored commit of Y".
I sometimes use that when I need to push other coworkers code for whatever reason, or when you start a codebase from an old project files that weren't versioned (so that you are not the author of all the atrocities of the old code ;)
Yes, but it isn't limited to non-verified emails, you can do it with verified emails as well. I assume it's already used to obscure deliberate security compromises in forks etc.
There are many practical impersonation vectors. I assume Github is gonna have to require signed commits for profile links in the medium term future.
Why not add a small orange (!) icon next to the name for unverified emails, or a similar indicator? As a way of saying "this user claimed authorship, but we couldn't verify it".
When you commit from the Github page itself, a similar green "verified" check is shown, but if you do it from command line and then push nothing is shown. So the infrastructure for special verifications messages is there, and perhaps could be used.
It's possible to show the "verified" check when commiting from the command line, you just have to sign the commit with a PGP key, and associate said PGP key with your account on github.
This implies that assuring a commit's provenance is beyond the scope of git, which is wrong. Git supports cryptographic signing of commits for this purpose.
184 comments
[ 2.8 ms ] story [ 194 ms ] threadIf the only real security around attribution is "a cryptographic signature", GitHub could do a lot better in pushing this, making it essential part of the signup or "getting started" and such.
Sure if you clone the git repo you get the e-mail address, but then you also won't get any information about who the email belongs to on Github.
I don't see how the design of Git affects this issue. This is simply one if clause away from being solved in Githubs frontend source code. Just check if email.verified: display the user, else, don't do that.
In the else-case all you'd get is a situation where one unknown user has Linus e-mail in their list of e-mail addresses, in Githubs DB, and a bunch of git commit logs with the same e-mail. No one would ever make the connection from the commit log to the list of Emails in the DB. Because the e-mail hasn't been verified. It's as simple as that to me but I could be wrong.
But if there's no record of someone at all then there isn't an easy way to detect this kind of abuse.
no? git just has an email field on the commit. it's github that has decided to allow people to associate unverified emails with their accounts, and also display this association whereever the email is listed in a commit.
and how exactly would this be out of character for the real Linus Torvalds?
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
1 - Don't associate the commit to an account if the email is unverified, obviously
2 - If someone tries to "forge" ownership by pushing a commit with an e-mail that doesn't belong to the GitHub account being used to push, a "unverified" warning should be added to the commit and manually claimed by the account owning said e-mail for its status to change.
The email field is for humans, who can lie, and shouldn't be used as authoritative by github.
they said unverified, not marked as a forgery
> The email field is for humans, who can lie, and shouldn't be used as authoritative by github.
and your solution is just to have everything marked as unverified, including commits that I push using my credentials and contain an email that I've verified with 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.
You could just run a script which rewrites the email address in all the git commits, and force-push the revised version.
> 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.
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?
[1] https://git-scm.com/docs/gitmailmap
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.
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.
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.
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.
For the very reason mentioned in this article: people can claim the commits without verification.
"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.
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.
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.
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"
Neither of these is ideal but at least the second one never tells lies.
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.
https://docs.github.com/en/authentication/managing-commit-si...
https://www.devopsauthority.tech/2020/07/18/github-getting-s...
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.
> 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.
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
Not just the linked page, the homepage too. All but illegible. That's in a recent Firefox on Windows. Just FYI.
We should really just tell Windows users to upgrade to a real operating system, rather than go out of our way to support it.
You really think businesses like Repography should just ignore the OS with 80% marketshare?
Imagine you did some work at some workplace years ago, and you want credit for it. You don't have access to that email anymore, but you'd still like to have the credit and have it link to your account. That's the usecase.
If it's not GitHub's responsibility, then why are they doing it? Nobody forces GitHub to attribute commits to GitHub user accounts. (And yes, you answer this "why" question in your next sentence, I'm just pointing out that your argument is nonsensical.)
Sure, I could claim an original Unix dev's work. But what does that actually do, besides raise questions I can't answer at interviews?
At the very least, repo owners should have some better control over how attributions display when the user is not a project member or the email used is not verified to an existing user.
It’s old news.
If so then it's probably fine since you would have to demonstrate ownership of an e-mail address that was contained in the signed payload, or you would have to be able to sign payloads yourself (i.e. you have the private key).
so.. does it do anything interesting with stuff like git blame -CCC which shows the genealogy of copypasta across time within a repo?
Colleague files an issue with a PR. Project owners close it, say 'no, not a bug', then... commits the same thing themselves as "fixed!". Saw this years before in cvs/svn, and... at least in the GH world there's some evidence of the original PR author having done the work in the first place (vs being invisibly cut out).
One the one hand, it’s his repo and he’s free to do whatever he wants. I actually admire how ruthless the maintainer is on closing issues, must be great for staving off OSS burnout.
On the other hand, I don’t love how antagonistic it is to outside contributors. Litestream[0] is an example of open source-closed contributions, but at least it’s upfront about that in the README. (And the policy has actually changed to open for bug fixes.) I would open an issue/PR on Huey suggesting adding a similar disclaimer, but it’d probably be closed, ha.
[0] https://github.com/benbjohnson/litestream#contribution-polic...
there's also the issue of being told "no, that's not a bug" or "no, WONTFIX", then... hours or days later... producing the same code patch as your own. Definitely a jerk move.
Some projects by nature attract high quality PRs. Others, like a game I built, have the unfortunate curse of attracting PRs with such low quality that it's kinda heart-breaking to shut them down.
It's one thing to read a good feature request in a Github issue and build it yourself. It's a whole other thing to modify a low quality PR in a polite way, see what they were trying to do, clean it up, refactor it. It can easily be 5x the work of just doing it from scratch as the project maintainer.
This experience, especially after your hundredth time, can jade you in a way and make you seem rude when you decide it's not worth the courtesy nor charity.
I'm sure it's frustrating when maintaining a fairly popular OSS tool to receive a PR that's 95% of the way there. Having to go back and forth to coach someone on getting that last 5% (or the contributor just dropping the PR then ghosting) vs just doing it yourself, I totally get it.
However from the contributor's point of view, when GH has support for co-authored commits, it comes of as a bit of jerky move when you take the time to submit a PR to not at least get credit via a co-author commit message.
Maybe instead of "taking the time to submit a PR" you should first submit an issue and only work on substantial code changes you are going to become emotionally invested in after you've negotiated the correct path forward with the maintainer? Open source used to be about communication and collaboration, not cowboy coding.
But if my version of the code has substantial changes (ie changes beyond just whitespace, small tweaks to the code, changing the commit message), I push it to a branch and ask the PR author to review and approve it first. Only after they approve it do I merge it into master and close the PR.
I also retain the GIT_AUTHOR of the original PR so that they still get credit; my user is only the GIT_COMMITTER. And I add a "Closes #" ref to the GH PR in the commit message so that it can be tracked later. git also has a de-facto standard of having multiple authors for a commit via `Co-authored-by:` lines in the commit message. This is useful for when my contribution is large enough to be equivalent to the PR author's.
Note that this doesn't work for workflows that require signed commits. If you have such a workflow, you have to go back to giving feedback and waiting for the PR author to make changes.
While everyone else who uses the project suffers with the bug that was being fixed as they wait for the person who contributed the patch to go through some hazing process involving code formatting that they (hopefully: I realize some people are in it mostly for the GitHub gamification credit of being a "contributor" on their landing page and thereby will do absolutely anything to get exactly and precisely the author credit on the commit) didn't sign up for. No: please for the love of everyone you are responsible for just commit the fix and thank the person later.
I've lately been feeling bad, and thinking I must look like an ungrateful asshat, about closing lower quality PRs (IMHO) with valid bugfixes but which introduces some new, possibly subtle, bug instead. Or having to close abandoned PRs because the submitter gave up before that last polishing to match the standard of my own repo. :(
Now I feel better knowing that I can do that final polish myself, while keeping the submitters original contrib!
That will save so much time and energy having to deal with back-and-forths or abandoned PRs
I am following a ton of issues on projects like Flutter and Cargo that are somehow steeped in this culture and it frankly just seems like nothing ever gets fixed. In some cases pull requests are open for years as people bike shed back and forth arguing over some extremely minor point in a patch, letting thousands of other developers suffer waiting for a patch that to them would work exactly the same either way, because of some weird culture that has been built up surrounding "maintainers may only click commit or leave comments while contributors type all of the code", and if the person who made the patch doesn't want to--or simply can't as they grok the requirement--satisfy some procedural process the world now has to wait for someone else to step up and submit themselves to this process with a new pull request, despite the maintainers having clearly all spent hours typing comments nitpicking on what at the end of the day is often literally a 30 line patch they apparently refuse to just re-type themselves.
In some sense I frankly think this is an entitlement issue on both sides: the maintainer isn't entitled to the continued time and effort of the person who submitted the patch--and certainly isn't committed to them doing exactly what the maintainer wants--and nor is the submitter entitled to some weird GitHub-specific contributor "credit" on the maintainer's project and the requisite control over the patch and how it gets applied that getting that would have to imply.
Should the patch submitter get some love? Yes! Is the bug tracker sufficient? Maybe! (I will say for myself this is absolutely sufficient: unless I am fixing some world-shaking bug--which does happen given what J do--the most important thing to me is going to be getting the feature or fix I wanted landed with minimal delay and preferably the least effort from me, not a very specific form of control over a commit.) If not, is having a file somewhere of "helpful people" enough? I want to say "yes", and I'll up it to "certainly" if it includes a mention of why.
But like, I really do think there is something super core going wrong with the open source world here, and this "pull request" model from GitHub with "contributor" status is to blame :/. In addition to the obviously-evil gamification of the codebase (from the badges) I think one reason people get this feeling of entitlement over their patch is that they put way too much work into it before it even gets presented as they go for this completed pull request model. 99.99% of the time what I want as a maintainer isn't someone who spent a month working on a patch that they are now going to argue with me about: I want a single paragraph a month earlier with an explanation of what is needed and maybe I could have solved it in a few hours or explained why the concept won't work or would conflict with planned effort.
On the other side, I then think the UI--combined with this inferred expectation from the patcher--forms that brutal entitlement from many maintainers that they maybe never have to touch code again and can just armchair quarterback / long-range pair program other people into getting some exact result. This is what chases away the quality contributors, as the quality contributors know that reformatting code is easy but p...
Having your name in the credits brings some of your reputation to their project. Having 'name brand' contributors is a benefit all its own for many projects.
https://news.ycombinator.com/item?id=21025378
Also, semi-related, obligatory mention of my joke utility for stealing credit for someone else's work:
https://github.com/silasx/git-upstage
Finally, I thought this phrasing was funny, like commits have a non-substantively transferable ownership, like an NFT (though FYI it's quoting an older discussion of the same problem):
>Someone wrote about the whole situation on Medium in November 2021: "The 1st commit of git/git no longer belongs to Linus Torvalds".
I don't mind that much, but I think I've seen these posts hitting the front page quite a lot already - it's a good strategy but it could be maybe against the guidelines:
> Please don't use HN primarily for promotion. It's ok to post your own stuff occasionally, but the primary use of the site should be for curiosity.
[1] https://repography.com/blog/go-first-commit
They could show statistics and attribution limited to the data available in the commit messages (e.g. accumulated statistics by e-mail address) for contributors without a GitHub profile.
Am I missing something here? (Edit: just read the other comments addressing the use cases)
However, if another profile verified that email address, it definitely shouldn't link to another profile that hasn't verified
I don't know how to handle this situation. It is somewhat easy to verify that a commit today comes from an email address I control now. However if I claim an unverified commit from years back is it really me just because I now control that email?
>which can directly relate to employment opportunities.
doesn't seem right.
Agreed on the copyright part of the equation, but I don't think many people take the commit author on GitHub as the copyright owner.
This seems to me to be the least important aspect of whatever is happening.
> can directly relate to employment opportunities
Given how free we are in choosing work, it seems to me you could just go work for a workplace that doesn't trawl through your charity history to figure out you're worthy enough. That's a matter of self-respect, which you should absolutely have.
That said, clearly users shouldn't be ascribing any level of certainty to commits that point to a GitHub profile even if the email address is verified, since AFAIK nothing is stopping the inverse attack, i.e. having someone else take credit for your work. Which is arguably more exploitable.
Does GitHub allow you to impersonate Linus via email? No, it does not.
If “Alice” adds alice@example.test to their account, GitHub will check if the email is not associated to an existing account, and then proceed to handle the request. Then, when “Bob” tries to add the same email to their account, GitHub prints the following error message “ Error adding alice@example.test: email is already in use.”
In your example, GitHub will display the username of the first user to add the (unverified) email to their account.
We got so many of these submissions which are clearly called out in the rules/scope, usually the people who don't read the rules don't find anything useful. ¯\_(ツ)_/¯
https://android.googlesource.com/platform/packages/apps/Glob...
Discussed in https://news.ycombinator.com/item?id=17487441
Note that git already provides a way to mark a commit with someone else authorship, but in that case you remain as the "original author" of the commit, usually shown as "X authored commit of Y". I sometimes use that when I need to push other coworkers code for whatever reason, or when you start a codebase from an old project files that weren't versioned (so that you are not the author of all the atrocities of the old code ;)
There are many practical impersonation vectors. I assume Github is gonna have to require signed commits for profile links in the medium term future.
When you commit from the Github page itself, a similar green "verified" check is shown, but if you do it from command line and then push nothing is shown. So the infrastructure for special verifications messages is there, and perhaps could be used.
Is it possible to use without connecting my user at all?