Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PyPI Blog: Project Quarantine

blog.pypi.org

Post reply on HN
Print view View original

21–30 of 62 posts

Re: PyPI Blog: Project Quarantine

#21

Post by LtWorf »

openrisk wrote: post #20

Its always an interesting dynamic: assuming a high trust society pays dividends - Python would be nowhere close the success it has been without PyPI. But then success attracts trust abusers and forces raising the fences (which comes with higher costs, both direct and indirect). Direct costs in the people and infrastructure that must be dedicated to the task. Indirect costs in the frictions generated by complicating w…

They won't pay anything unless they are forced to do so. Basic capitalism brings to externalise costs to society

Re: PyPI Blog: Project Quarantine

#23

Post by LtWorf »

woodruffw wrote: post #17
IshKebab wrote: post #10

The still don't even have a way to avoid dependency confusion attacks when using private package repos (other than also registering every single private package name you use on pypi.org). Blows my mind.

Who is "they"? PyPI is an index; it doesn't control your installing client. (This is a larger issue - or feature, depending on your perspective - with Python packaging. But it's important to understand that PyPI itself can't force `pip` or any other client to pick any particular resolution order between indices.)

For all intents and purposes "pip" is the official client. It is referenced in the official documentation https://docs.python.org/3/installing/index.html

Re: PyPI Blog: Project Quarantine

#24

Post by oefrha »

> The one project cleared was a project containing obfuscated code, in violation of the PyPI Acceptable Use Policy.

Interesting, I didn’t know that. While I haven’t released anything obfuscated on PyPI, I’ve certainly written Python projects that include obfuscated code by necessity, namely scrapers packing duktape (embedded JS interpreter) and third party obfuscated JS blobs to generate signatures and stuff. I know for a fact there are projects like that on PyPI. I wonder if those are allowed.

(Come to think of it, those probably can be DMCAed if the targeted service provider is sufficiently motivated.)

Re: PyPI Blog: Project Quarantine

#25

Post by woodruffw »

LtWorf wrote: post #23
woodruffw wrote: post #17

Earlier quoted context omitted.

Who is "they"? PyPI is an index; it doesn't control your installing client. (This is a larger issue - or feature, depending on your perspective - with Python packaging. But it's important to understand that PyPI itself can't force `pip` or any other client to pick any particular resolution order between indices.)

For all intents and purposes "pip" is the official client. It is referenced in the official documentation https://docs.python.org/3/installing/index.html

The fact that pip is the official client isn’t in dispute. The point was that pip and PyPI are different entities, per a larger pattern of devolved ownership/control/standards-over-tools in Python packaging. PyPI has little to no say over how pip and other tools choose to handle resolutions across multiple indices.

Re: PyPI Blog: Project Quarantine

#26

Post by pyper-dev »

oefrha wrote: post #24

> The one project cleared was a project containing obfuscated code, in violation of the PyPI Acceptable Use Policy. Interesting, I didn’t know that. While I haven’t released anything obfuscated on PyPI, I’ve certainly written Python projects that include obfuscated code by necessity, namely scrapers packing duktape (embedded JS interpreter) and third party obfuscated JS blobs to generate signatures and stuff. I know…

[dead]

Re: PyPI Blog: Project Quarantine

#27

Post by pjc50 »

xgstation wrote: post #11

the fact that `pip install` just runs whatever is in `setup.py` is still mind baffling, even if the author weren't mallicious the `setup.py` can still do harm (say delete a file by mistake), there really needs to be an official way of sandbox its running.

I don't think that makes much of a difference from the risk of bugs in the rest of the package when it's run.

Re: PyPI Blog: Project Quarantine

#28

Post by xgstation »

ogrisel wrote: post #19
xgstation wrote: post #11

the fact that `pip install` just runs whatever is in `setup.py` is still mind baffling, even if the author weren't mallicious the `setup.py` can still do harm (say delete a file by mistake), there really needs to be an official way of sandbox its running.

Note that it's possible to disable that behavior with `pip install --only-binary :all:`. This way, pip will fail if a dependency does not provide a `.whl` package, instead of automatically falling back to the "build from source" mode that can lead to arbitrary code execution at install time (via setuptools' `setup.py` or any other build backend mechanism). However, installing from wheels just protects from arbitrary…

I think sometimes the problem is coming from accidental typos instead of not trusting, say if one accidentally typed `pip install requests` into `pip install requestss` and if `requestss` is malacious then by the time one noticed the typo the setup.py could have already run to do the harm

Re: PyPI Blog: Project Quarantine

#29

Post by xgstation »

woodruffw wrote: post #18
xgstation wrote: post #11

the fact that `pip install` just runs whatever is in `setup.py` is still mind baffling, even if the author weren't mallicious the `setup.py` can still do harm (say delete a file by mistake), there really needs to be an official way of sandbox its running.

It's not good, but it should also not be baffling: it's the exact same thing other ecosystems do (npm with install hooks/scripts, Rust with build.rs, Ruby with gemspecs, etc).

I know other ecosystems do the same and those are baffling too, especially for the newer created languages like rust, which is why https://internals.rust-lang.org/t/pre-rfc-sandboxed-determin... exists

Re: PyPI Blog: Project Quarantine

#30

Post by IshKebab »

woodruffw wrote: post #17
IshKebab wrote: post #10

The still don't even have a way to avoid dependency confusion attacks when using private package repos (other than also registering every single private package name you use on pypi.org). Blows my mind.

Who is "they"? PyPI is an index; it doesn't control your installing client. (This is a larger issue - or feature, depending on your perspective - with Python packaging. But it's important to understand that PyPI itself can't force `pip` or any other client to pick any particular resolution order between indices.)

> Who is "they"?

The PyPI and Pip developers of course.

Post reply on HN