2 ms·

The problem described in the post isn't the fault of package naming schemes, it's due to `pip install --extra-index-url` apparently ignoring the user-specified

by kibwen 4y ago

The problem described in the post isn't the fault of package naming schemes, it's due to `pip install --extra-index-url` apparently ignoring the user-specified registry if the package exists on PyPI, which, if true, is baffling, because it throws out the concept of private registries altogether in favor of treating PyPI as some sort of universal namespace.

0cf8612b2e1e 4y ago
That Github issue is insane. So frustrating that an obviously wrong behavior is continued even after exploits in the wild. Count me as one of those idiot users who was confused by the current behavior.
Triesault 4y ago
> due to `pip install --extra-index-url` apparently ignoring the user-specified registry if the package exists on PyPI I thought this was the expected behavior of --extra-index-url To force pip to use a user-specified registry, you would use --index-url instead of --extra-index-url
SOLAR_FIELDS 4y ago
We ran into a pretty serious vulnerability around editable installs last year as well. Nearly the same story as here - basically an editable install hit an edge case and went to pypi instead when you wouldn’t expect it to. Python has not thought this problem through nearly as much as the Java people have.
Too 4y ago
To be fair, the parameter is called extra index url, not private index url. That there is no other option for private repositories or namespacing is still a big shame.
- smarnach 4y ago
  There is, as already pointed out in a sibling comment, and it's called --index-url: https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-0 https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-0
vsl 4y ago
> The problem described in the post isn't the fault of package naming schemes If PyPI used Java-like scheme with domain ownership verification, Google would presumably use com.google.* namespace for their private stuff and it wouldn’t be possible to introduce malicious package this way. So the described issue arguably is a consequence of that.

by kibwen 4y ago

0cf8612b2e1e 4y ago

That Github issue is insane. So frustrating that an obviously wrong behavior is continued even after exploits in the wild. Count me as one of those idiot users who was confused by the current behavior.

Triesault 4y ago

> due to `pip install --extra-index-url` apparently ignoring the user-specified registry if the package exists on PyPI I thought this was the expected behavior of --extra-index-url To force pip to use a user-specified registry, you would use --index-url instead of --extra-index-url

SOLAR_FIELDS 4y ago

We ran into a pretty serious vulnerability around editable installs last year as well. Nearly the same story as here - basically an editable install hit an edge case and went to pypi instead when you wouldn’t expect it to. Python has not thought this problem through nearly as much as the Java people have.

Too 4y ago

To be fair, the parameter is called extra index url, not private index url. That there is no other option for private repositories or namespacing is still a big shame.

smarnach 4y ago
There is, as already pointed out in a sibling comment, and it's called --index-url: https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-0 https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-0

vsl 4y ago

> The problem described in the post isn't the fault of package naming schemes If PyPI used Java-like scheme with domain ownership verification, Google would presumably use com.google.* namespace for their private stuff and it wouldn’t be possible to introduce malicious package this way. So the described issue arguably is a consequence of that.