3 ms·

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 shoul

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.
  - dragonwriter 9y ago
    > A package manager would only be vulnerable if that package manager is a transparent proxy to Github A central-repository package manager that doesn't either enforce immutability or at least have strong protection against a deleted project being replaced with a same-name project poses the same risk, only with itself rather than GitHub and the target. There are package managers that are safe against this, but I don't think it is yet the norm.
    - kibwen 9y ago
      Agreed that any package manager that allows deletion and replacement is broken. However the OP is referring to Github specifically, which was not designed with the same requirements as a package manager; as much as I think it would be an improvement to prevent Github usernames from being reclaimed, this is a problem with Go encouraging people to depend upon Github URLs directly, not really with Github itself.
  - krapp 9y ago
    As far as I know (and correct me if I'm wrong) but NPM only manages a database of package names, most of which link to Github repos themselves. And NPM at least until recently allowed name reuse.
    - kibwen 9y ago
      NPM requires one to log in to NPM before pushing new versions of a package, to which control of a specific Github username has no bearing. And I know of no way to "link" an NPM library to a Github repo, publishing requires a local copy and an explicit action: https://docs.npmjs.com/getting-started/publishing-npm-packages https://docs.npmjs.com/getting-started/publishing-npm-packag... And yes, NPM allowed name reuse, and that was bad, but that was a problem on NPM's side, not Github's side, because NPM is supposed to be a robust package repository and Github was just designed to be a lightweight social network for programmers.
    - always_good 9y ago
      No, NPM hosts the tarballs itself. A project is not linked to a Github repo at all. It's just taken for granted that the repository on the tin (if there is one) is what you're getting when you npm install.

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.
- dragonwriter 9y ago
  > A package manager would only be vulnerable if that package manager is a transparent proxy to Github A central-repository package manager that doesn't either enforce immutability or at least have strong protection against a deleted project being replaced with a same-name project poses the same risk, only with itself rather than GitHub and the target. There are package managers that are safe against this, but I don't think it is yet the norm.
  - kibwen 9y ago
    Agreed that any package manager that allows deletion and replacement is broken. However the OP is referring to Github specifically, which was not designed with the same requirements as a package manager; as much as I think it would be an improvement to prevent Github usernames from being reclaimed, this is a problem with Go encouraging people to depend upon Github URLs directly, not really with Github itself.
- krapp 9y ago
  As far as I know (and correct me if I'm wrong) but NPM only manages a database of package names, most of which link to Github repos themselves. And NPM at least until recently allowed name reuse.
  - kibwen 9y ago
    NPM requires one to log in to NPM before pushing new versions of a package, to which control of a specific Github username has no bearing. And I know of no way to "link" an NPM library to a Github repo, publishing requires a local copy and an explicit action: https://docs.npmjs.com/getting-started/publishing-npm-packages https://docs.npmjs.com/getting-started/publishing-npm-packag... And yes, NPM allowed name reuse, and that was bad, but that was a problem on NPM's side, not Github's side, because NPM is supposed to be a robust package repository and Github was just designed to be a lightweight social network for programmers.
  - always_good 9y ago
    No, NPM hosts the tarballs itself. A project is not linked to a Github repo at all. It's just taken for granted that the repository on the tin (if there is one) is what you're getting when you npm install.