4 ms·

This only seems to be an issue for languages where packages reside in a global namespace, like Python, Rust etc. I think most languages these days are a bit sm

This only seems to be an issue for languages where packages reside in a global namespace, like Python, Rust etc. I think most languages these days are a bit smarter and avoid this beginner mistake (for various reasons).

abiox 10y ago
this is yet another reason why i really wished rust had went for namespaced packaging on crates.io. i like so many of the decisions the rust team made, but not this one.
vemv 10y ago
Ruby and JS package managers are un-namespaced as well.
- SixSigma 10y ago
  Julia too, though there is a central list. I haven't done any tests for this kind of thing.
anentropic 10y ago
couldn't you register a typo namespace?
- Klathmon 10y ago
  Yes, but then you'd need to also register a ton of packages under that namespace. That's something that can be flagged for manual review before it gets too far.
  - anentropic 10y ago
    maybe I don't understand the namespaces... but if you are targeting a package `someuser/popularpackage` can you not just register your own malicious `popularpackage` under a typo namespace like `smoeuser`?
    - Klathmon 10y ago
      Yes, but my thought was it gives a bit more "data" to work with on the package manager's side. They can see someone registering popular package names under something with a similar namespace and can flag them for manual review (which can be done for namespace-less packages, but there will be much more noise), they can apply things like "This is the first time you are installing a package from 'smoeuser' would you like to continue?", or even require adding a specific namespace "out of band" depending on how paranoid it wants to be.
      - kibwen 10y ago
        > "This is the first time you are installing a package > from 'smoeuser' would you like to continue?" You don't need package namespacing for this. All package repositories already require a registered account to publish a package.
        Klathmon 10y ago
        That's a good point, but honestly I wouldn't be able to tell you the account names of any of the packages i use regularly. And unless the account name of the package maintainers is brought front-and-center, you aren't necessarily going to know it shouldn't be different until it's too late.
        kibwen 10y ago
        A user doesn't need to be able to recognize the account name, that's the purpose of your aforementioned prompt. Let's consider the possible scenarios for installing "foo/bar": I. I've installed anything from the author "foo" before on this machine, implying that I trust "foo". A. On a system with namespaced packages, I attempt to install "fpp/bar". I've never installed anything from the author "fpp" before, so I get a prompt. B. On a system without namespaced packages, I attempt to install "bsr". 1. If "bsr" is by an author I trust, then it will be installed. This will be confusing, but is not a security vulnerability. because this author is already running code on my machines. 2. If "bsr" is by an author I don't trust, then I get a prompt, as in scenario I.A. II. I've never installed anything from the author "foo" before on this machine. A. On a system with namespaced packages, I attempt to install "fpp/bar". The system prompts me, as in scenario I.A., but because I expect this prompt I don't bother reading it and blindly accept it. The prompt does reiterate the name of the author, but if I didn't catch the typo the first time, there's little chance I'll catch the typo this time. Remember: the value of the prompt is not the reiteration of the name, it's in its unexpected nature, because research has repeatedly shown that users, even power users, do not bother reading routine prompts (this is why, e.g., Chrome no longer allows users to bypass the enormously scary warning page that appears when a secure site has a certificate error). My system gets owned. B. On a system without namespaced packages, I attempt to install "bsr". The system prompts me, as in scenario I.A., but because I expect this prompt I don't bother reading it and blindly accept it. My system gets owned. A more complete version of the solution that you're proposing would be to have an actual implementation of a web of trust, but even that doesn't solve all the security problems inherent to package repositories.
tatterdemalion 10y ago
This is obviously not true. If `serde` resided at `erickt/serde` (as the counterproposal for Rust would've had it), I could create `erict/serde` or `erick-t/serde` or any other variations of erickt's handle. The only way this is 'solved' is if some third party authority hands out top level names and refuses to register names that are similar to other names for some definition of similar. The number of levels between top level and package name is irrelevant.
- zardeh 10y ago
  Well, you could also solve it by saying that the post slash names are unique. ie. There can't exist zardeh/serde if erickt/serde already exists. Then the author-name works as a logical checksum, and you aren't any worse off than you were with a global namespace.
  - tatterdemalion 10y ago
    That reduces the likelihood of success (erick-t/srede requires 2 typos) but doesn't eliminate the possibility.
    - zardeh 10y ago
      True, but two simultaneous and specific typos is much, much less likely than a single one.
  - kibwen 10y ago
    The purpose of a namespace is to make it possible to disambiguate two otherwise identical identifiers. If you force package names to be unique across all namespaces, then you don't have namespaces at all, you just have a single global namespace where you're forced to prepend an author name to the package name.
    - zardeh 10y ago
      I know, I wasn't suggesting this as a namespacing solution, but instead a typo-prevention one.
kibwen 10y ago
This is incorrect. Package repositories with namespacing are just as vulnerable to these attacks.
- airless_bar 10y ago
  Wrong.
  - kibwen 10y ago
    Say that a popular package lives at `jack/foo`. An attacker needs only register `jakc` and create a package `foo`, and now anyone typing `blah install jakc/foo` is owned. There's a reason why "namespacing" isn't listed under the "Defenses against typo squatting" section.
    - airless_bar 10y ago
      Just read my other reply.

abiox 10y ago

this is yet another reason why i really wished rust had went for namespaced packaging on crates.io. i like so many of the decisions the rust team made, but not this one.

vemv 10y ago

Ruby and JS package managers are un-namespaced as well.

SixSigma 10y ago
Julia too, though there is a central list. I haven't done any tests for this kind of thing.

anentropic 10y ago

couldn't you register a typo namespace?

Klathmon 10y ago
Yes, but then you'd need to also register a ton of packages under that namespace. That's something that can be flagged for manual review before it gets too far.
- anentropic 10y ago
  maybe I don't understand the namespaces... but if you are targeting a package `someuser/popularpackage` can you not just register your own malicious `popularpackage` under a typo namespace like `smoeuser`?
  - Klathmon 10y ago
    Yes, but my thought was it gives a bit more "data" to work with on the package manager's side. They can see someone registering popular package names under something with a similar namespace and can flag them for manual review (which can be done for namespace-less packages, but there will be much more noise), they can apply things like "This is the first time you are installing a package from 'smoeuser' would you like to continue?", or even require adding a specific namespace "out of band" depending on how paranoid it wants to be.
    - kibwen 10y ago
      > "This is the first time you are installing a package > from 'smoeuser' would you like to continue?" You don't need package namespacing for this. All package repositories already require a registered account to publish a package.
      - Klathmon 10y ago
        That's a good point, but honestly I wouldn't be able to tell you the account names of any of the packages i use regularly. And unless the account name of the package maintainers is brought front-and-center, you aren't necessarily going to know it shouldn't be different until it's too late.
        kibwen 10y ago
        A user doesn't need to be able to recognize the account name, that's the purpose of your aforementioned prompt. Let's consider the possible scenarios for installing "foo/bar": I. I've installed anything from the author "foo" before on this machine, implying that I trust "foo". A. On a system with namespaced packages, I attempt to install "fpp/bar". I've never installed anything from the author "fpp" before, so I get a prompt. B. On a system without namespaced packages, I attempt to install "bsr". 1. If "bsr" is by an author I trust, then it will be installed. This will be confusing, but is not a security vulnerability. because this author is already running code on my machines. 2. If "bsr" is by an author I don't trust, then I get a prompt, as in scenario I.A. II. I've never installed anything from the author "foo" before on this machine. A. On a system with namespaced packages, I attempt to install "fpp/bar". The system prompts me, as in scenario I.A., but because I expect this prompt I don't bother reading it and blindly accept it. The prompt does reiterate the name of the author, but if I didn't catch the typo the first time, there's little chance I'll catch the typo this time. Remember: the value of the prompt is not the reiteration of the name, it's in its unexpected nature, because research has repeatedly shown that users, even power users, do not bother reading routine prompts (this is why, e.g., Chrome no longer allows users to bypass the enormously scary warning page that appears when a secure site has a certificate error). My system gets owned. B. On a system without namespaced packages, I attempt to install "bsr". The system prompts me, as in scenario I.A., but because I expect this prompt I don't bother reading it and blindly accept it. My system gets owned. A more complete version of the solution that you're proposing would be to have an actual implementation of a web of trust, but even that doesn't solve all the security problems inherent to package repositories.

tatterdemalion 10y ago

This is obviously not true. If `serde` resided at `erickt/serde` (as the counterproposal for Rust would've had it), I could create `erict/serde` or `erick-t/serde` or any other variations of erickt's handle. The only way this is 'solved' is if some third party authority hands out top level names and refuses to register names that are similar to other names for some definition of similar. The number of levels between top level and package name is irrelevant.

zardeh 10y ago
Well, you could also solve it by saying that the post slash names are unique. ie. There can't exist zardeh/serde if erickt/serde already exists. Then the author-name works as a logical checksum, and you aren't any worse off than you were with a global namespace.
- tatterdemalion 10y ago
  That reduces the likelihood of success (erick-t/srede requires 2 typos) but doesn't eliminate the possibility.
  - zardeh 10y ago
    True, but two simultaneous and specific typos is much, much less likely than a single one.
- kibwen 10y ago
  The purpose of a namespace is to make it possible to disambiguate two otherwise identical identifiers. If you force package names to be unique across all namespaces, then you don't have namespaces at all, you just have a single global namespace where you're forced to prepend an author name to the package name.
  - zardeh 10y ago
    I know, I wasn't suggesting this as a namespacing solution, but instead a typo-prevention one.

kibwen 10y ago

This is incorrect. Package repositories with namespacing are just as vulnerable to these attacks.

airless_bar 10y ago
Wrong.
- kibwen 10y ago
  Say that a popular package lives at `jack/foo`. An attacker needs only register `jakc` and create a package `foo`, and now anyone typing `blah install jakc/foo` is owned. There's a reason why "namespacing" isn't listed under the "Defenses against typo squatting" section.
  - airless_bar 10y ago
    Just read my other reply.