12 ms·

GitHub shouldn't allow username reuse

216 points by donatj 9y ago

3pt14159 9y ago
They should only be reused if manually requested. Sometimes usernames had nothing on them (thus a manual enable is ok) and freeing up the username after a couple years of seeing no traffic seems fine too. But really I kinda shudder to think of how much stuff is hackable just by stealing the right laptop and phone while someone is on vacation.
- dgacmu 9y ago
  There should be a way to verify that the repo you're depending on has activated strong 2FA and opted in to a minimum waiting period for name reuse.
eclipticplane 9y ago
When I did a large organization rename (GitHub helped us reclaim a name from a long-since disused account), we were extremely cautious because of this exact problem. Our GitHub organization was named XYZ, being renamed to ABC. We had GitHub rename a separate user, DEF, to ABC. We then picked a low risk time and had browser windows open when we initiated the swap of our new shiny ABC to ABC-old to immediately grab the name and then immediately grab the old name on a new account.
- netsharc 9y ago
  So... they allow account takeovers without any grace periods? Amazing.
  - compsciphd 9y ago
    uh, did you read what the OP wrote? he said a long since disused account. i.e. how long a grace period do you desire they have? github's general policy is that if an account has been dormant for a year (which might mean not just means commits, but also fetches from it) its can be recycled. This is because they dont want to enable username squatting.
    - rileymat2 9y ago
      How does this work with third party login? For instance I can use my github accout to log in to gitlab. Seems like a security risk for even dormant accounts.
      - knownothing 9y ago
        I'd imagine all OAuth tokens associated with an account are rolled when it's transferred.
        rileymat2 9y ago
        I was not clear, github works as an identity provider. I am not talking about api access to github, I am talking about using github to log into other services.
      - compsciphd 9y ago
        I'd assume that any use of github services (such as use of a token) keeps the account non dormant.
kenhwang 9y ago
Or maybe Github shouldn't be used as a package repository if security is a concern.
- sergiotapia 9y ago
  I also think it's weird how Go uses Github HEAD as the package download source. Strange.
  - artursapek 9y ago
    You can use tools like glide to lock in a particular revision, like package-lock.json with NPM.
    - zeveb 9y ago
      > You can use tools like glide Ah, the new hotness is dep (as opposed to godep, as opposed to govendor). I love Go, but man if it doesn't have a bit of JavaScript's reïmplement-the-world problem. The funny thing to me is that this was always pointed to as a problem of Lisps: Lisp is so powerful that a student can implement an object system as homework, and the issue is that every student will. It looks like this problem isn't limited to Lisp: any sufficiently-powerful language enables programmers to reïnvent the wheel rather than forcing them to collaborate (e.g. as with C, where doing anything is so incredibly difficult that it's easier to pitch in with someone else's project than start your own).
      - artursapek 9y ago
        go dep hilarious fails to work with private repos. It just hangs whenever I try running it. Looking through its source code it looks like it's actually just a fork of glide.
        zeveb 9y ago
        It works for us, with GitHub private repos. We already have each repo checked out locally, though, so perhaps git is already aware of our credentials? Also, it may not be hanging but merely running for a very long time. Sometimes I'll start dep, then head to lunch. It's … not the fastest thing ever.
dasil003 9y ago
Title is a little bit hyperbolic. I get that it's a real issue that needs fixing, but a GitHub URL is not a secure package identifier, it was never designed this way, and it's an unfortunate hack that it's become a defacto standard. What we really need is for language-level package managers to support signed immutable packages, and for that to start being taken seriously above the OS-level. Edit: author changed the title, it used to say something about a "GitHub's security facepalm"
- tomphoolery 9y ago
  > but a GitHub URL is not a secure package identifier, it was never designed this way, and it's an unfortunate hack that it's become a defacto standard. Thank you. GitHub shouldn't be the only line of defense between a malicious coder and your software.
- Demiurge 9y ago
  I tried to debug Go project once, and the moment I saw that, I was completely shocked that it was importing from github urls, without even tags, or versions as far as I could tell. It seems dangerous to rely on a for-profit host and individual users. If 'network' dependencies are part of the language, it should at least be non-profit, or better Go project managed host. There are many examples, like PyPi, or PECL.
  - dewey 9y ago
    That's what vendoring and dependency tools are for.
  - crdoconnor 9y ago
    That was the first wtf I hit when learning go that made me think that it possibly wasn't all it was cracked up to be.
  - ovao 9y ago
    Go doesn't specifically rely on GitHub, but it can pull in dependencies with a simplified URL that points to a git repository hosted on GitHub. This is possible because GitHub renders an HTML meta tag on project pages that the go tool can reference to fetch information about the repository. Anyone can actually 'reflect' dependencies hosted with various VCS with this method, and gopkg.in does essentially this (while adding version pinning).
mehrdadn 9y ago
This reasoning is wrong to me. I see this very much as a problem with using usernames to refer to repositories in the first place, not with username reuse. For heaven's sake, let me just refer to a repo by a unique ID of its own. There's no reason for the username to be in the repository URL.
- gumby 9y ago
  Hear hear! Fixing the real problem.
- tomphoolery 9y ago
  here's one reason: `git clone some-user/some-repo`
  - mehrdadn 9y ago
    Oh come on, this is not a justification, it's just complete laziness. Just spend the extra 5 seconds copying the repo URL from GitHub. It's not like you can avoid that the first time around when you don't know the username anyway (or on subsequent times for that matter, unless the username is pretty memorable), and you'll have a robust URL afterwards without security holes. And plus, then people can change their usernames without breaking links. The cost/benefit ratio is extremely low.
- TheRealPomax 9y ago
  So, a sha1 commit hash, which gives you an exact filesystem snapshot, and can't be faked with identical content if someone gets their hands on someone's account? The real issue is Go just pointing to "whatever is the current HEAD" which is insane.
  - mehrdadn 9y ago
    No, a commit hash points to a commit. This is for when we want to point to a repo, i.e. For exactly the same situations where we currently use URLs with usernames.
sanderjd 9y ago
This seems akin to a new server receiving an existing IP address. If I ssh to that IP address after the change, it tells me the server's fingerprint has changed and I have to make an explicit choice to trust the new server. It seems like this could be made to work similarly.
- Shoothe 9y ago
  And this explicit choice is not some Y/N decision that can be easily overlooked but it's editing known hosts, so that the user understands the seriousness.
tjpd 9y ago
Isn’t this the developer’s or Go’s security issue first before it’s a GH facepalm? GH doesn’t make any representations about the provenance or the safety of the code on their site. It is the user and toolchain that’s making those potentially dangerous assumption, no? Doesn’t blocking id reuse open them up to a kind of ID squatting and DOS?
- edem 9y ago
  That's the exact reason that they do have a name squatting policy: https://help.github.com/articles/name-squatting-policy/ https://help.github.com/articles/name-squatting-policy/ I am definitely against this nonsense. Don't depend on some third party for your solutions who never said that their urls are here to stay. Quite the contrary!
  - mcphage 9y ago
    Huh. Someone once offered to buy my github username from me... I had no idea that was explicitly against their policy. (Not that I said yes, or had any interest in selling)
    - edem 9y ago
      But if you wish to use a name GitHub will mediate between you and the owner. Never worked for me but it can happen.
drinchev 9y ago
This reminds me about the whole `left-pad` fiasco and npm allowing same-name packages to be re-published. For a while I thought that the packages were hijacked [1]. GitHub should definitely not allow username reuse, but most prominently it's a Go issue, where they use GitHub as a package manager. 1 : http://www.drinchev.com/blog/alert-npm-modules-hijacked/ http://www.drinchev.com/blog/alert-npm-modules-hijacked/
q3k 9y ago
Another reason to always vendor [1] your dependencies... [1] - https://github.com/golang/dep https://github.com/golang/dep
- donatj 9y ago
  Even then, if you ever update your dependencies the problem could strike.
ecshafer 9y ago
This is insane. Not that the username was reused, but rather that people are using a direct link to GitHub as their dependency management. At minimum you should manually fork it into a repo you control, but a proper package manager is what is really necessary. Would you statically link to an ftp server in your code build process? What about to a random website for a piece of code? No, you wouldn't, and this is equally unprofessional.
- donatj 9y ago
  A package manager would be just as vulnerable, as mentioned in the post. Just with a delay until you run update.
  - kuschku 9y ago
    A package manager wouldn't allow deletion. For f*s sake, the Java ecosystem is horrible and yet even they managed to get this right. Maven Central doesn't allow deletion (except in very rare cases, and in those the packages were available in other repos), as result you can always rely on those packages staying available. You can import, and be done. Every dependency you declare has an explicit version as well. The go and JS dependency management solutions are pure madness
    - brabel 9y ago
      > the Java ecosystem is horrible ... Oh, what a low move. Whatever you consider the Java ecosystem to be, it's used by most large companies, millions of developers and has been one of the most successful, scandal-free ecosystems in the programming world... if you think that's horrible, you must explain yourself, otherwise you're just being a dick.
  - kibwen 9y ago
    A package manager would be vulnerable (to package hijacking via reclaimed Github username) only if that package manager is a transparent proxy to Github. Any package manager with its own central package repo, like NPM and RubyGems, would be unaffected by a reclaimed Github username. Even a package repo like crates.io, which uses Github to authenticate, wouldn't be vulnerable because user equivalence is by user ID rather than username.
halayli 9y ago
The security facepalm is the fact that you're pulling source code without signature verification. It's not github's responsibility to manage usernames. The blame and responsibility is on Go and whoever thought it's a good idea to pull in code this way. There are so many scenarios were you can end up cloning malicious code when you're simply relying on cloning alone. What if someone hacked the author's github account and committed malicious code? And why do you trust that the author has no plans in the future to inject malicious code?
- mehrdadn 9y ago
  > The security facepalm is the fact that you're pulling source code without signature verification. > And why do you trust that the author has no plans in the future to inject malicious code? Signature verification is used to protect against malicious authors now?
- ashelmire 9y ago
  Did you just say it's not github's responsibility to manage usernames on their own site? You're aware that attacks on similar names (not even exact ones) are a very common form of security attack, right? What signature verification would one have when accessing a public repo? If I tell somebody there's a really great tool at fakename/faketool, they are screwed.
  - paxy 9y ago
    Github has the right to "manage usernames" however they see fit. The problem is that a third party is making assumptions about these usernames and basing their entire security mechanism on it, even though that assumption is incorrect, and now they're blaming Github for it.
  - dumbneurologist 9y ago
    Not quite: his/her point is that it's on the user to validate the author as opposed to the location. If you care about security, you should pull from a repo, then check a against a signature. Your https connection confirms you got something from github, but you have the ability to prove the thing you got from github was from the same individual.
AdmiralAsshat 9y ago
There's a similar problem in the Kodi world where a popular repo was deactivated then re-registered by another party: https://torrentfreak.com/metalkettle-after-github-takeover-170915/ https://torrentfreak.com/metalkettle-after-github-takeover-1...
ocdtrekkie 9y ago
Had a conversation in 2015 with someone who was... a bit of an irritant. Future people tagging him in like 2017... ended up dragging in a completely innocent bystander. Because the guy in question had changed his account name, someone else has registered his old one, and GitHub, cluelessly, attached all of his comments to the new user.
hnruss 9y ago
Another facepalm in the comments section: > What did GitHub say when you reported it per https://help.github.com/articles/github-security/ https://help.github.com/articles/github-security/ ? ... > I did not report it. ...
- mehrdadn 9y ago
  This is not exactly an obscure scenario. If I was a better I would bet >10:1 odds they had already thought through this scenario and dismissed it for whatever reason (maybe equating it with having an irresponsible or malicious package author), i.e. reporting it wouldn't have done anything.
  - hnruss 9y ago
    True, but we don't know for sure. If we're making guesses, I'd guess that someone made the decision about username re-use years ago-- before package management systems began relying on GitHub directly. If that is the case, then this issue could not have even been considered.
- donatj 9y ago
  The choice of where to ... the response is a little editorialized.
  - hnruss 9y ago
    I don't make a lot of comments on HN, so I could use some constructive criticism on how to improve. My intent was to highlight content relevant to my point. Any suggestions on how I could do this better (maybe better formatting)?
di 9y ago
Hmm, it seems the same issue exists with domain names, we should probably prevent them from being reused as well. /s
edem 9y ago
Don't blame GitHub for Go's clearly broken dependency solutions. What everybody should have learned after so many incidents like this is this: an artifact should only be deletable by nuclear fire GitHub has a name squatting policy for a reason. I have multiple "names" because some guy's repo who abandoned GitHub years ago was released and I was able to reuse it for my own brand. This is like saying if I buy a domain it should be mine for eternity even if it is no longer useful for me. More about the squatting policy here: https://help.github.com/articles/name-squatting-policy/ https://help.github.com/articles/name-squatting-policy/
rocky1138 9y ago
Why are packages from Github not given a unique hash as opposed to being tied to a username in the URL?
clhodapp 9y ago
In short: "My toolchain chose to do a thing that is insecure given your (publicly-known) approach to managing your usernames. Now I am exposed to a security vulnerability and it's your fault!" No! This is the go ecosystem's fault! It was knowable that GitHub managed usernames this way and yet they still chose to introduce this security risk.
niftich 9y ago
This situation arises solely from Go's myriad dependency management tools [1], including the latest "official experiment" 'go dep', not having the notion of a package repository. Instead, package identity is tightly bound to package location [2], and doing "package management" on this identity results in HTTP GETs or equivalents to that location. This is documented as a core convention [2] of the Go world, by the designers themselves. I was always bewildered by this choice [3][4], because many, many other package management systems have independently realized this to be a bad idea -- and that it's valuable to have an extra layer of indirection between package identity and package location to prevent this exact situation. The component that solves this indirection is called a package repository, which can then institute strict rules about immutability, deletions, and naming, if so desired. NPM didn't, for a long time, until they got burned. GitHub is not a package repository, but due to the Go community's guidance, is effectively being used as such in a large volume of Go code in the wild. [1] https://github.com/golang/go/wiki/PackageManagementTools https://github.com/golang/go/wiki/PackageManagementTools [2] https://golang.org/doc/articles/go_command.html#tmp_1 https://golang.org/doc/articles/go_command.html#tmp_1 [3] https://news.ycombinator.com/item?id=12189356 https://news.ycombinator.com/item?id=12189356 [4] https://news.ycombinator.com/item?id=15677338 https://news.ycombinator.com/item?id=15677338
- cdoxsey 9y ago
  You can override the location of a package with dep. Indirection doesn't solve the problem it just moves it to the centralized repository. Go designers recommend vendoring packages which solves the problem.
  - niftich 9y ago
    > "You can override the location of a package with dep." As far as I know, this is true [1], and can be done with the 'source' rule in Gopkg.toml. However, the guidance for dep says [1]: "A source rule can specify an alternate location from which the name'd project should be retrieved. It is primarily useful for temporarily specifying a fork for a repository. source rules are generally brittle and should only be used when there is no other recourse. Using them to try to circumvent network reachability issues is typically an antipattern." This doesn't sound like a glowing endorsement of this feature. > "Indirection doesn't solve the problem it just moves it to the centralized repository." Precisely; we're in agreement. A repository can then choose to institute sensible rules, if they so desire: Maven Central has what I would consider to be sensible rules, while NPM prior to 'left-pad' did not. Without a repository, the community has no place to make this decision point, so everyone's left to fend for themselves. > "Go designers recommend vendoring packages which solves the problem." Can you point me to guidance from Go designers which substantiates your point? I have been searching for this and have been unable to find it. [1] https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md
smnscu 9y ago
The article raises a good point, but I just wanted to take the time to praise GitHub's support, who've been repeatedly super helpful in helping me get inactive handles (including my own @andreis). It's definitely a far cry from other services like Twitter.
jlg23 9y ago
Where does it concern GitHub's security model? This is a serious question, I am not a GitHub user myself. The only thing I get from the article is "people treat URLs as eternal, even if the site does not provide strong guarantees for that." But that is not news and moot to debate, as a site's policy can change anytime and then you are still screwed. And nothing of this is specific to GitHub.
buserror 9y ago
I'm glad they allow reuse. I signed up very early on github, but my username was already taken... By someone who didn't contribute anything at all to anything, ever; and probably never used the account again. One day, after many years, I emailed the github guys to know if I possibly get it, and they immediately, and very kindly agreed and renamed me.
ljm 9y ago
The more I read about some issues with Go, the more I realise that it's beautiful and elegant because of the ties with Plan9 and the uncomplicated thinking that comes with it, but it suffers greatly because it won't consider how the world has changed since. So you get a very particular way of doing things (`GOPATH`, `gofmt`) and you're kind of out of luck when the abstraction leaks (`interface {}`). Point in case: treat GitHub as part of the filesystem, so you don't need to host a package manager. I suspect that the end game is the opposite of Java (com.example/package/whatever) and in the long run you're expected to publish your source to a domain you control. Starting with GitHub and services like gopkg.in just gets people acquainted with the idea but in the enterprise you'll be importing `enterprise.com/factory/builder` or some such.
ixtli 9y ago
Many people appear to be accusing the author of being hyperbolic, saying "well, you shouldn't be relying on github urls being real." This is true, but it misses the point: whether they should have or not, people ARE using the technology in this way. GitHub can either take an ideological stand and continue allowing people to be unknowingly exposed to an attack surface, or they can make a reasonable effort to defend against malicious usage of their service. Perhaps there are material reasons why it would be wrong or prohibitively difficult for them to change their username policy, but if it isn't, I don't think it's unreasonable to request this of them while simultaneously admonishing people who assuming data from github will always be accurate. Put another way, I would _also_ upvote an article that said "The Go package manager is insecure because it assumes github URLs never change owners."
- netheril96 9y ago
  > while simultaneously admonishing people who assuming data from github will always be accurate. Admonishing how? The change of policy would motivate them to do nothing at all, perpetuating the mistake.
- edem 9y ago
  The malicious use here is treating GitHub as a package repository. GitHub should not do anything about this other than explicitly stating that GitHub is not a package repository and they cannot be held accountable for using GitHub in a really dumb way.
  - ishanjain28 9y ago
    +9000 Votes to you edem.
    - edem 9y ago
      Then it will be ... over nine thousand!
EtDybNuvCu 9y ago
Using nixpkgs, this isn't a problem because the source hashes will mismatch if somebody tries to spoof a username with a malicious repository. We should all be using Nix more often.
tonyztan 9y ago
It is important to note that domain names can also be reused, and a lot of trust is assigned to certain domain names, too.
deleted 9y ago
[deleted]
Everlag 9y ago
(Context: I'm here late into the conversation and after the title was changed) When you consider github.com/foo/bar you see that foo has established a reputation by developing code for third party use. Can foo break upstream builds that rely on HEAD? Absolutely. However, given that foo has a reputation for high quality content is it likely for them, barring an exceptional event, to insert malicious code? Probably not. The issue I have with github allowing username reuse in a broader context is that the reputation from a trusted user is transferred to a third party. That third party could be neutral, well meaning, or malicious. All the same, they should not be able to take the reputation developed by that user. In this example, if foo decides to become a bespoke tailor and deletes their github, someone should not be able to use their reputation. In the context of go using urls as canonical locations for code, is it smelly? Oh yeah. Does that mean that username reuse isn't a problem? No. A lot of people here are pointing at either go developers or github. You can blame both and eventually get a robust solution from both.
s_chaudhary 9y ago
I like the way gitlab approaches this. On gitlab if you change your username, the old username can't be used by anyone again. I have faced this problem with github. I changed my username. The very next day, someone created an account with my old username and now all my resume, old profiles etc. were pointing to an empty github account. :(

216 points by donatj 9y ago

They should only be reused if manually requested. Sometimes usernames had nothing on them (thus a manual enable is ok) and freeing up the username after a couple years of seeing no traffic seems fine too. But really I kinda shudder to think of how much stuff is hackable just by stealing the right laptop and phone while someone is on vacation.

dgacmu 9y ago
There should be a way to verify that the repo you're depending on has activated strong 2FA and opted in to a minimum waiting period for name reuse.

eclipticplane 9y ago

When I did a large organization rename (GitHub helped us reclaim a name from a long-since disused account), we were extremely cautious because of this exact problem. Our GitHub organization was named XYZ, being renamed to ABC. We had GitHub rename a separate user, DEF, to ABC. We then picked a low risk time and had browser windows open when we initiated the swap of our new shiny ABC to ABC-old to immediately grab the name and then immediately grab the old name on a new account.

netsharc 9y ago
So... they allow account takeovers without any grace periods? Amazing.
- compsciphd 9y ago
  uh, did you read what the OP wrote? he said a long since disused account. i.e. how long a grace period do you desire they have? github's general policy is that if an account has been dormant for a year (which might mean not just means commits, but also fetches from it) its can be recycled. This is because they dont want to enable username squatting.
  - rileymat2 9y ago
    How does this work with third party login? For instance I can use my github accout to log in to gitlab. Seems like a security risk for even dormant accounts.
    - knownothing 9y ago
      I'd imagine all OAuth tokens associated with an account are rolled when it's transferred.
      - rileymat2 9y ago
        I was not clear, github works as an identity provider. I am not talking about api access to github, I am talking about using github to log into other services.
    - compsciphd 9y ago
      I'd assume that any use of github services (such as use of a token) keeps the account non dormant.

kenhwang 9y ago

Or maybe Github shouldn't be used as a package repository if security is a concern.

sergiotapia 9y ago
I also think it's weird how Go uses Github HEAD as the package download source. Strange.
- artursapek 9y ago
  You can use tools like glide to lock in a particular revision, like package-lock.json with NPM.
  - zeveb 9y ago
    > You can use tools like glide Ah, the new hotness is dep (as opposed to godep, as opposed to govendor). I love Go, but man if it doesn't have a bit of JavaScript's reïmplement-the-world problem. The funny thing to me is that this was always pointed to as a problem of Lisps: Lisp is so powerful that a student can implement an object system as homework, and the issue is that every student will. It looks like this problem isn't limited to Lisp: any sufficiently-powerful language enables programmers to reïnvent the wheel rather than forcing them to collaborate (e.g. as with C, where doing anything is so incredibly difficult that it's easier to pitch in with someone else's project than start your own).
    - artursapek 9y ago
      go dep hilarious fails to work with private repos. It just hangs whenever I try running it. Looking through its source code it looks like it's actually just a fork of glide.
      - zeveb 9y ago
        It works for us, with GitHub private repos. We already have each repo checked out locally, though, so perhaps git is already aware of our credentials? Also, it may not be hanging but merely running for a very long time. Sometimes I'll start dep, then head to lunch. It's … not the fastest thing ever.

dasil003 9y ago

Title is a little bit hyperbolic. I get that it's a real issue that needs fixing, but a GitHub URL is not a secure package identifier, it was never designed this way, and it's an unfortunate hack that it's become a defacto standard. What we really need is for language-level package managers to support signed immutable packages, and for that to start being taken seriously above the OS-level. Edit: author changed the title, it used to say something about a "GitHub's security facepalm"

tomphoolery 9y ago
> but a GitHub URL is not a secure package identifier, it was never designed this way, and it's an unfortunate hack that it's become a defacto standard. Thank you. GitHub shouldn't be the only line of defense between a malicious coder and your software.
Demiurge 9y ago
I tried to debug Go project once, and the moment I saw that, I was completely shocked that it was importing from github urls, without even tags, or versions as far as I could tell. It seems dangerous to rely on a for-profit host and individual users. If 'network' dependencies are part of the language, it should at least be non-profit, or better Go project managed host. There are many examples, like PyPi, or PECL.
- dewey 9y ago
  That's what vendoring and dependency tools are for.
- crdoconnor 9y ago
  That was the first wtf I hit when learning go that made me think that it possibly wasn't all it was cracked up to be.
- ovao 9y ago
  Go doesn't specifically rely on GitHub, but it can pull in dependencies with a simplified URL that points to a git repository hosted on GitHub. This is possible because GitHub renders an HTML meta tag on project pages that the go tool can reference to fetch information about the repository. Anyone can actually 'reflect' dependencies hosted with various VCS with this method, and gopkg.in does essentially this (while adding version pinning).

mehrdadn 9y ago

This reasoning is wrong to me. I see this very much as a problem with using usernames to refer to repositories in the first place, not with username reuse. For heaven's sake, let me just refer to a repo by a unique ID of its own. There's no reason for the username to be in the repository URL.

gumby 9y ago
Hear hear! Fixing the real problem.
tomphoolery 9y ago
here's one reason: `git clone some-user/some-repo`
- mehrdadn 9y ago
  Oh come on, this is not a justification, it's just complete laziness. Just spend the extra 5 seconds copying the repo URL from GitHub. It's not like you can avoid that the first time around when you don't know the username anyway (or on subsequent times for that matter, unless the username is pretty memorable), and you'll have a robust URL afterwards without security holes. And plus, then people can change their usernames without breaking links. The cost/benefit ratio is extremely low.
TheRealPomax 9y ago
So, a sha1 commit hash, which gives you an exact filesystem snapshot, and can't be faked with identical content if someone gets their hands on someone's account? The real issue is Go just pointing to "whatever is the current HEAD" which is insane.
- mehrdadn 9y ago
  No, a commit hash points to a commit. This is for when we want to point to a repo, i.e. For exactly the same situations where we currently use URLs with usernames.

sanderjd 9y ago

This seems akin to a new server receiving an existing IP address. If I ssh to that IP address after the change, it tells me the server's fingerprint has changed and I have to make an explicit choice to trust the new server. It seems like this could be made to work similarly.

Shoothe 9y ago
And this explicit choice is not some Y/N decision that can be easily overlooked but it's editing known hosts, so that the user understands the seriousness.

tjpd 9y ago

Isn’t this the developer’s or Go’s security issue first before it’s a GH facepalm? GH doesn’t make any representations about the provenance or the safety of the code on their site. It is the user and toolchain that’s making those potentially dangerous assumption, no? Doesn’t blocking id reuse open them up to a kind of ID squatting and DOS?

edem 9y ago
That's the exact reason that they do have a name squatting policy: https://help.github.com/articles/name-squatting-policy/ https://help.github.com/articles/name-squatting-policy/ I am definitely against this nonsense. Don't depend on some third party for your solutions who never said that their urls are here to stay. Quite the contrary!
- mcphage 9y ago
  Huh. Someone once offered to buy my github username from me... I had no idea that was explicitly against their policy. (Not that I said yes, or had any interest in selling)
  - edem 9y ago
    But if you wish to use a name GitHub will mediate between you and the owner. Never worked for me but it can happen.

drinchev 9y ago

This reminds me about the whole `left-pad` fiasco and npm allowing same-name packages to be re-published. For a while I thought that the packages were hijacked [1]. GitHub should definitely not allow username reuse, but most prominently it's a Go issue, where they use GitHub as a package manager. 1 : http://www.drinchev.com/blog/alert-npm-modules-hijacked/ http://www.drinchev.com/blog/alert-npm-modules-hijacked/

q3k 9y ago

Another reason to always vendor [1] your dependencies... [1] - https://github.com/golang/dep https://github.com/golang/dep

donatj 9y ago
Even then, if you ever update your dependencies the problem could strike.

ecshafer 9y ago

This is insane. Not that the username was reused, but rather that people are using a direct link to GitHub as their dependency management. At minimum you should manually fork it into a repo you control, but a proper package manager is what is really necessary. Would you statically link to an ftp server in your code build process? What about to a random website for a piece of code? No, you wouldn't, and this is equally unprofessional.

donatj 9y ago
A package manager would be just as vulnerable, as mentioned in the post. Just with a delay until you run update.
- kuschku 9y ago
  A package manager wouldn't allow deletion. For f*s sake, the Java ecosystem is horrible and yet even they managed to get this right. Maven Central doesn't allow deletion (except in very rare cases, and in those the packages were available in other repos), as result you can always rely on those packages staying available. You can import, and be done. Every dependency you declare has an explicit version as well. The go and JS dependency management solutions are pure madness
  - brabel 9y ago
    > the Java ecosystem is horrible ... Oh, what a low move. Whatever you consider the Java ecosystem to be, it's used by most large companies, millions of developers and has been one of the most successful, scandal-free ecosystems in the programming world... if you think that's horrible, you must explain yourself, otherwise you're just being a dick.
- kibwen 9y ago
  A package manager would be vulnerable (to package hijacking via reclaimed Github username) only if that package manager is a transparent proxy to Github. Any package manager with its own central package repo, like NPM and RubyGems, would be unaffected by a reclaimed Github username. Even a package repo like crates.io, which uses Github to authenticate, wouldn't be vulnerable because user equivalence is by user ID rather than username.

halayli 9y ago

The security facepalm is the fact that you're pulling source code without signature verification. It's not github's responsibility to manage usernames. The blame and responsibility is on Go and whoever thought it's a good idea to pull in code this way. There are so many scenarios were you can end up cloning malicious code when you're simply relying on cloning alone. What if someone hacked the author's github account and committed malicious code? And why do you trust that the author has no plans in the future to inject malicious code?

mehrdadn 9y ago
> The security facepalm is the fact that you're pulling source code without signature verification. > And why do you trust that the author has no plans in the future to inject malicious code? Signature verification is used to protect against malicious authors now?
ashelmire 9y ago
Did you just say it's not github's responsibility to manage usernames on their own site? You're aware that attacks on similar names (not even exact ones) are a very common form of security attack, right? What signature verification would one have when accessing a public repo? If I tell somebody there's a really great tool at fakename/faketool, they are screwed.
- paxy 9y ago
  Github has the right to "manage usernames" however they see fit. The problem is that a third party is making assumptions about these usernames and basing their entire security mechanism on it, even though that assumption is incorrect, and now they're blaming Github for it.
- dumbneurologist 9y ago
  Not quite: his/her point is that it's on the user to validate the author as opposed to the location. If you care about security, you should pull from a repo, then check a against a signature. Your https connection confirms you got something from github, but you have the ability to prove the thing you got from github was from the same individual.

AdmiralAsshat 9y ago

There's a similar problem in the Kodi world where a popular repo was deactivated then re-registered by another party: https://torrentfreak.com/metalkettle-after-github-takeover-170915/ https://torrentfreak.com/metalkettle-after-github-takeover-1...

ocdtrekkie 9y ago

Had a conversation in 2015 with someone who was... a bit of an irritant. Future people tagging him in like 2017... ended up dragging in a completely innocent bystander. Because the guy in question had changed his account name, someone else has registered his old one, and GitHub, cluelessly, attached all of his comments to the new user.

hnruss 9y ago

Another facepalm in the comments section: > What did GitHub say when you reported it per https://help.github.com/articles/github-security/ https://help.github.com/articles/github-security/ ? ... > I did not report it. ...

mehrdadn 9y ago
This is not exactly an obscure scenario. If I was a better I would bet >10:1 odds they had already thought through this scenario and dismissed it for whatever reason (maybe equating it with having an irresponsible or malicious package author), i.e. reporting it wouldn't have done anything.
- hnruss 9y ago
  True, but we don't know for sure. If we're making guesses, I'd guess that someone made the decision about username re-use years ago-- before package management systems began relying on GitHub directly. If that is the case, then this issue could not have even been considered.
donatj 9y ago
The choice of where to ... the response is a little editorialized.
- hnruss 9y ago
  I don't make a lot of comments on HN, so I could use some constructive criticism on how to improve. My intent was to highlight content relevant to my point. Any suggestions on how I could do this better (maybe better formatting)?

di 9y ago

Hmm, it seems the same issue exists with domain names, we should probably prevent them from being reused as well. /s

edem 9y ago

Don't blame GitHub for Go's clearly broken dependency solutions. What everybody should have learned after so many incidents like this is this: an artifact should only be deletable by nuclear fire GitHub has a name squatting policy for a reason. I have multiple "names" because some guy's repo who abandoned GitHub years ago was released and I was able to reuse it for my own brand. This is like saying if I buy a domain it should be mine for eternity even if it is no longer useful for me. More about the squatting policy here: https://help.github.com/articles/name-squatting-policy/ https://help.github.com/articles/name-squatting-policy/

rocky1138 9y ago

Why are packages from Github not given a unique hash as opposed to being tied to a username in the URL?

clhodapp 9y ago

In short: "My toolchain chose to do a thing that is insecure given your (publicly-known) approach to managing your usernames. Now I am exposed to a security vulnerability and it's your fault!" No! This is the go ecosystem's fault! It was knowable that GitHub managed usernames this way and yet they still chose to introduce this security risk.

niftich 9y ago

This situation arises solely from Go's myriad dependency management tools [1], including the latest "official experiment" 'go dep', not having the notion of a package repository. Instead, package identity is tightly bound to package location [2], and doing "package management" on this identity results in HTTP GETs or equivalents to that location. This is documented as a core convention [2] of the Go world, by the designers themselves. I was always bewildered by this choice [3][4], because many, many other package management systems have independently realized this to be a bad idea -- and that it's valuable to have an extra layer of indirection between package identity and package location to prevent this exact situation. The component that solves this indirection is called a package repository, which can then institute strict rules about immutability, deletions, and naming, if so desired. NPM didn't, for a long time, until they got burned. GitHub is not a package repository, but due to the Go community's guidance, is effectively being used as such in a large volume of Go code in the wild. [1] https://github.com/golang/go/wiki/PackageManagementTools https://github.com/golang/go/wiki/PackageManagementTools [2] https://golang.org/doc/articles/go_command.html#tmp_1 https://golang.org/doc/articles/go_command.html#tmp_1 [3] https://news.ycombinator.com/item?id=12189356 https://news.ycombinator.com/item?id=12189356 [4] https://news.ycombinator.com/item?id=15677338 https://news.ycombinator.com/item?id=15677338

cdoxsey 9y ago
You can override the location of a package with dep. Indirection doesn't solve the problem it just moves it to the centralized repository. Go designers recommend vendoring packages which solves the problem.
- niftich 9y ago
  > "You can override the location of a package with dep." As far as I know, this is true [1], and can be done with the 'source' rule in Gopkg.toml. However, the guidance for dep says [1]: "A source rule can specify an alternate location from which the name'd project should be retrieved. It is primarily useful for temporarily specifying a fork for a repository. source rules are generally brittle and should only be used when there is no other recourse. Using them to try to circumvent network reachability issues is typically an antipattern." This doesn't sound like a glowing endorsement of this feature. > "Indirection doesn't solve the problem it just moves it to the centralized repository." Precisely; we're in agreement. A repository can then choose to institute sensible rules, if they so desire: Maven Central has what I would consider to be sensible rules, while NPM prior to 'left-pad' did not. Without a repository, the community has no place to make this decision point, so everyone's left to fend for themselves. > "Go designers recommend vendoring packages which solves the problem." Can you point me to guidance from Go designers which substantiates your point? I have been searching for this and have been unable to find it. [1] https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md

smnscu 9y ago

The article raises a good point, but I just wanted to take the time to praise GitHub's support, who've been repeatedly super helpful in helping me get inactive handles (including my own @andreis). It's definitely a far cry from other services like Twitter.

jlg23 9y ago

Where does it concern GitHub's security model? This is a serious question, I am not a GitHub user myself. The only thing I get from the article is "people treat URLs as eternal, even if the site does not provide strong guarantees for that." But that is not news and moot to debate, as a site's policy can change anytime and then you are still screwed. And nothing of this is specific to GitHub.

buserror 9y ago

I'm glad they allow reuse. I signed up very early on github, but my username was already taken... By someone who didn't contribute anything at all to anything, ever; and probably never used the account again. One day, after many years, I emailed the github guys to know if I possibly get it, and they immediately, and very kindly agreed and renamed me.

ljm 9y ago

The more I read about some issues with Go, the more I realise that it's beautiful and elegant because of the ties with Plan9 and the uncomplicated thinking that comes with it, but it suffers greatly because it won't consider how the world has changed since. So you get a very particular way of doing things (`GOPATH`, `gofmt`) and you're kind of out of luck when the abstraction leaks (`interface {}`). Point in case: treat GitHub as part of the filesystem, so you don't need to host a package manager. I suspect that the end game is the opposite of Java (com.example/package/whatever) and in the long run you're expected to publish your source to a domain you control. Starting with GitHub and services like gopkg.in just gets people acquainted with the idea but in the enterprise you'll be importing `enterprise.com/factory/builder` or some such.

ixtli 9y ago

Many people appear to be accusing the author of being hyperbolic, saying "well, you shouldn't be relying on github urls being real." This is true, but it misses the point: whether they should have or not, people ARE using the technology in this way. GitHub can either take an ideological stand and continue allowing people to be unknowingly exposed to an attack surface, or they can make a reasonable effort to defend against malicious usage of their service. Perhaps there are material reasons why it would be wrong or prohibitively difficult for them to change their username policy, but if it isn't, I don't think it's unreasonable to request this of them while simultaneously admonishing people who assuming data from github will always be accurate. Put another way, I would _also_ upvote an article that said "The Go package manager is insecure because it assumes github URLs never change owners."

netheril96 9y ago
> while simultaneously admonishing people who assuming data from github will always be accurate. Admonishing how? The change of policy would motivate them to do nothing at all, perpetuating the mistake.
edem 9y ago
The malicious use here is treating GitHub as a package repository. GitHub should not do anything about this other than explicitly stating that GitHub is not a package repository and they cannot be held accountable for using GitHub in a really dumb way.
- ishanjain28 9y ago
  +9000 Votes to you edem.
  - edem 9y ago
    Then it will be ... over nine thousand!

EtDybNuvCu 9y ago

Using nixpkgs, this isn't a problem because the source hashes will mismatch if somebody tries to spoof a username with a malicious repository. We should all be using Nix more often.

tonyztan 9y ago

It is important to note that domain names can also be reused, and a lot of trust is assigned to certain domain names, too.

deleted 9y ago

[deleted]

Everlag 9y ago

(Context: I'm here late into the conversation and after the title was changed) When you consider github.com/foo/bar you see that foo has established a reputation by developing code for third party use. Can foo break upstream builds that rely on HEAD? Absolutely. However, given that foo has a reputation for high quality content is it likely for them, barring an exceptional event, to insert malicious code? Probably not. The issue I have with github allowing username reuse in a broader context is that the reputation from a trusted user is transferred to a third party. That third party could be neutral, well meaning, or malicious. All the same, they should not be able to take the reputation developed by that user. In this example, if foo decides to become a bespoke tailor and deletes their github, someone should not be able to use their reputation. In the context of go using urls as canonical locations for code, is it smelly? Oh yeah. Does that mean that username reuse isn't a problem? No. A lot of people here are pointing at either go developers or github. You can blame both and eventually get a robust solution from both.

s_chaudhary 9y ago

I like the way gitlab approaches this. On gitlab if you change your username, the old username can't be used by anyone again. I have faced this problem with github. I changed my username. The very next day, someone created an account with my old username and now all my resume, old profiles etc. were pointing to an empty github account. :(