3 ms·

Namespacing does not prevent (or even significantly complicate) dependency confusion, unless we think that there's some difference in confusability between thes

Namespacing does not prevent (or even significantly complicate) dependency confusion, unless we think that there's some difference in confusability between these two errors: requestss and requestss/requests (I think namespacing is a good idea in general, but dependency confusion is mostly a disjoint namespaces problem, not a depth problem. Python could solve the former by doing what Go does and make the source repository itself be the namespace, but this a significant incompatible breakage.)

tczMUFlmoNk 3y ago
It helps in some cases. If I type `npm i @google/cloud-sotrage`, I'm still safe. Same with `@google/gcs` (typo vs. misremembering the name). I just have to get the organization name right.
ptx 3y ago
It does help in some cases. For example, I know that "kotlin-stdlib-jdk8" in Maven Central is the official package for Kotlin standard library, but what about "kotlin-stdlib-wasm-wasi", "kotlin-jdk-annotations" and "kotlin-native-compiler-embeddable"? Here it helps to know that they're all in the "org.jetbrains.kotlin" group.
IshKebab 3y ago
I think you have the wrong idea of what dependency confusion is. Here's the scenario: 1. Company develops package `company_secret_project_stuff` and publishes version 1 on their internal private PyPI instance. 2. They tell their employees to install it via `python3 -m pip install --extra-index-url https://pypi.intranet.company.com https://pypi.intranet.company.com company_secret_project_stuff` 3. pip dutifully goes and installs the hacker's version of `company_secret_project_stuff` (version 999999) from the global PyPI index. I know for a fact that my company is vulnerable to this. The only solution currently is for the company to also register `company_secret_project_stuff` on the global PyPI. But you can guess how happy they were about exposing internal package names. They opted to remain vulnerable instead (yes; stupid decision but I can kind of see their point). Namespaces trivially fix this. You just register the `@company` namespace on the global PyPI index and then make sure all your private packages are in that namespace. Attackers can't publish packages with the same name as yours, and you don't need to make them all public.
- failsecured 3y ago
  2 pip installs can trivially solve this issue and I use this at work. One pip install only for private packages using the --index-url (NOT --extra-index-url) and then the other pip install for public packages no index modifiers needed.
  - IshKebab 3y ago
    I don't think that works if the private packages depend on public ones, which is quite likely.
    - failsecured 3y ago
      You are completely correct. I neglected to mention that we mirror/cache the dependencies we need in our private index.

tczMUFlmoNk 3y ago

It helps in some cases. If I type `npm i @google/cloud-sotrage`, I'm still safe. Same with `@google/gcs` (typo vs. misremembering the name). I just have to get the organization name right.

ptx 3y ago

It does help in some cases. For example, I know that "kotlin-stdlib-jdk8" in Maven Central is the official package for Kotlin standard library, but what about "kotlin-stdlib-wasm-wasi", "kotlin-jdk-annotations" and "kotlin-native-compiler-embeddable"? Here it helps to know that they're all in the "org.jetbrains.kotlin" group.

IshKebab 3y ago

I think you have the wrong idea of what dependency confusion is. Here's the scenario: 1. Company develops package `company_secret_project_stuff` and publishes version 1 on their internal private PyPI instance. 2. They tell their employees to install it via `python3 -m pip install --extra-index-url https://pypi.intranet.company.com https://pypi.intranet.company.com company_secret_project_stuff` 3. pip dutifully goes and installs the hacker's version of `company_secret_project_stuff` (version 999999) from the global PyPI index. I know for a fact that my company is vulnerable to this. The only solution currently is for the company to also register `company_secret_project_stuff` on the global PyPI. But you can guess how happy they were about exposing internal package names. They opted to remain vulnerable instead (yes; stupid decision but I can kind of see their point). Namespaces trivially fix this. You just register the `@company` namespace on the global PyPI index and then make sure all your private packages are in that namespace. Attackers can't publish packages with the same name as yours, and you don't need to make them all public.

failsecured 3y ago
2 pip installs can trivially solve this issue and I use this at work. One pip install only for private packages using the --index-url (NOT --extra-index-url) and then the other pip install for public packages no index modifiers needed.
- IshKebab 3y ago
  I don't think that works if the private packages depend on public ones, which is quite likely.
  - failsecured 3y ago
    You are completely correct. I neglected to mention that we mirror/cache the dependencies we need in our private index.