GitHub Shouldn't Allow Username Reuse
Update 2018-04-19 - GitHub has implemented some rules around retiring "namespaces".
To prevent developers from pulling down potentially unsafe packages, we now retire the namespace of any open source project that had more than 100 clones in the week leading up to the owner’s account being renamed or deleted.
This is a decent half step but I'd still love to see either permalinks or every namespace of a user permanently retired once their account is deleted.
Update 2018-02-10 In discussing this with people online, I’ve come to the conclusion that the bigger, more important issue is lack of permalinks to repository instances. Path reuse, rather than username reuse.
There is a very popular tool for embedding data files into your Go binaries called go-bindata. Several days ago however the user who ran it, "Jim Teeuwen" (wayback machine), completely disappeared from the internet – deleting his GitHub account and personal domain in the process.
While this is within his rights to do, this broke a dependency many people had within their projects.
To fix this, some users of the project recreated the account and the repository based on a fork of the project.
They have an official announcement/disclosure here:
https://github.com/jteeuwen/go-bindata/issues/5
At the very least they are being honest about it.
The fact that they were allowed to do this however represents a fundamental flaw in GitHub's security model.
Usernames, once deleted, should never be allowed to be valid again. Many sites including Google do it this way.
Allowing username reuse completely breaks any trust that what I pull is what it claims to be.
What if this user had been malicious? It may have taken a while before someone actually noticed this wasn't the original user and the code was doing something more than it claimed to.
While Go's go get functionality is no doubt naive and just pulls the head of a repository, this is not exclusively Go's problem as this affects any package manager that runs on tags. Simply tag malicious changes beyond the current release and it would be deployed to many users likely with little actual review.
This should not be possible. This is scary and should be fixed.
Update
Many people are arguing that this is the developers fault or the package managers fault. I do not agree, but as far as I see it that doesn't matter anyway. The simple fact of the matter is that it is being used like that, like it or not, and the simplest and I argue most correct fix is for GitHub to prevent the issue.
I think another good option would be GitHub offering permalinks to repos, such that if they were deleted and recreated the pathing would change.
It affects not only package managers and programs and software, but humans. Humans navigating GitHub. I have no way to tell while navigating the site if a project is the original or a charade. That is a problem.
As for the title change, I agreed with Hacker News that the original was a bit hyperbolic. I have a tendency to resort to hyperbole to get my emotional point across - and it doesn't always read correctly on the internet.
Comment by: Alvin on
What did GitHub say when you reported it per https://help.github.com/articles/github-security/ ?Assuming you did, I could see adding that to the blog post so it’s clear that you followed responsible disclosure practices.
Comment by: Jesse G. Donat on
I did not report it – it's stated policy that they allow reuse, and I didn't see it as an "active security vulnerability" as much as a poor policy choice. A "facepalm" if you will.It's not much of an exploit, and the number of high profile package authors that delete their github account is probably extremely small.
Update: I did later end up offically reporting it via that form just for good measure.
Comment by: Adma Arold on
This is Go's facepalm actually. GitHub never claimed to be a package repository. Quite the contrary they explicitly stated that names will be released if certain conditions are met (more about this here: https://help.github.com/articles/name-squatting-policy/)This is like saying that once you claimed a domain it should belong to you for eternity even if you abandon it.
GitHub names are bound to entities like you or me (or an organization) and as such it is a perfectly valid thing for it to change.
That's why we have 410, Gone!
The authors of such package repository should have learned from Javascript's mistakes and should have written something like Maven Central where artifacts are here to stay.
Comment by: Punk on
you serious?
Github *is not* a package repository. Github *hosts* git repositories. To properly serve as a package repository, only the account which originally submitted the package should have the permission to submit new major versions, increment old ones with fixes (minor versions), and manage which accounts also receive these permissions. Everything submitted should also have a permanent, reserved address until the repository ceases to exist.
Comment by: Brad Erhart on
Something signed packages should handle. Keeping usernames unavailable is like keeping domain names unavailable. You end up with all the good ones taken but not used for anything meaningful.
Comment by: WhatTheOPSaid on
This very issue almost cost my company very recently! We have several tools that are dependencies of other Linux distros. Something I had no idea about is that when you change your username Github will initially create a transparent redirect so that people looking for the original content are redirected to your new content. That redirect will stay in tact even after the original username is claimed by someone else. It isn't until the new owner of the username creates the repo with the same name that the redirect is broken. However, if you have more than one repo all the other redirects continue to function. According to Github it is this way by design.
Comment by: jftr on
The original problem that you state is that malicious actors could take over repositories relied upon by package managers and consequently, malicious code could be distributed through package managers relying on GitHub.I don't see this as an issue of GitHub, a host for Git repositories, but a failure of package managers to verify sources. There are many ways to do just that. There is even a solution with minimal impact on the current workflow: Signed Tags.
Package managers use tags already for determining what commit to pull for a certain version. Why not only allow tags to be used that are signed by a trusted entity (authors, auditors, etc)? That way it doesn't matter where the source code is hosted and who has control of the repository. The new owners can add new tags as much as they want but they cannot change existing tags without changing the signature, too.
Comment by: Rob_vH on
GitHub is not a package repo, this may seem counter intuitive to users who mainly use it that way but it’s true nonetheless. package managers (mom, composer, dep, go get, etc) are greatly getting a free ride (well they’re free too, you are getting free ride) and should solve this problem.
Comment by: Marcin Kaszyński on
Package repo or not, allowing this kind of change to what a public URI breaks the net. It's not just a security issue, it also affects pages that just link to it.If I write an enthusiastic blog post about a tool I found on GH I'd rather not have to recheck whether it will still point to the same repo a year from now. If the author deletes the repo and account, then I would expect to see a 410.
Even if GitHub is open about what they do and why they do, this contributes to link rot in a very bad way.
Comment by: jftr on
@MarcinIf I write an enthusiastic blog post about a tool I found on GH I'd rather not have to recheck whether it will still point to the same repo a year from now. If the author deletes the repo and account, then I would expect to see a 410.
Whenever you link to anything outside GitHub, do you regularly recheck if the link is still valid and points to what you intended to reference?
That is exactly how the internet works. No one guarantees you that any page or even domain still hosts the same data you initially linked to and neither does anyone prevent new owners of a domain to host different data for the same URI. Neither are they obliged to return a 410.
Heck, even github.com could be taken over by new owners, for instance in case of bankruptcy.
As I see it, preventing GitHub usernames from being taken over only paints over some symptoms. The real problem is that package managers do not verify sources.
Comment by: Marcin Kaszyński on
@jftrThat is exactly how the internet works.
True. But it's not binary. You can use the same argument to absolve, say, a corporation that completely reworks their URI scheme so that articles and support pages referenced on user forums no longer point anywhere. Yes, that's how technically stuff works, and that happens often. It's still someone making a decision that is worse for customers, and we would be better off if that decision was made differently.
I don't expect domains or companies to be there forever, but within namespace under github.com, as long as GH exists and has continuity from its current state, they have a choice to either contribute to link rot or not. IMO they decided to make situation worse.
The real problem is [...]
You see the real problem where you see the real problem.
I don't expect GH to contribute much to package management, I'm just disappointed with the unnecessary, deliberate link rot.
Also, GH managed to build something that became an important part of the net for a lot of people. That's awesome, and that means they provide real value, by all means kudos to them. But that also means their decisions have more impact than a random startup's. Honestly, even without going to package managers: how many people validate repo contents when they clone it from GH and then execute a piece of code from it? How often you do it? You can dismiss that as massive PEBKAC, or you can say that GH is not explicit enough about the level of guarantees it provides. I'm with the latter.
hatoun salah