On Tue, Sep 20, 2016 at 1:42 PM Paul Moore <p.f.mo...@gmail.com> wrote:
> On 20 September 2016 at 00:28, אלעזר <elaz...@gmail.com> wrote: > > On Tue, Sep 20, 2016 at 2:20 AM Stephen J. Turnbull > > <turnbull.stephen...@u.tsukuba.ac.jp> wrote: > >> > >> אלעזר writes: > >> > >> > Another use case, though I admit not the top priority of anyone here, > >> is > >> > that of assignment checkers. In most courses I took at the > university, > >> the > >> > person who checks the assignments says something like "you are > allowed > >> to > >> > use only this this and this libraries", in order not to mess with > >> unknown > >> > dependencies from tens of students (I am talking about advanced > >> courses, > >> > where the method I use to solve the problem is unimportant or only > >> requires > >> > explanation). With this statement they can simply state "you can > import > >> > pip". > >> > >> In other words, you're advocating a feature that allows script writers > >> to download, install, and execute arbitrary, unsandboxed code on any > >> machine where the script is run. That sounds ... *scary*, when put > >> that way. Remember, you're advocating this on behalf of people who by > >> assumption are infants years below the age of consent. > >> > > Let me understand. Your argument is "installing pip modules is unsafe, > and > > therefore we should make it less usable, where the appropriate amount of > > (un)usability is running cmd and then `pip install unsafe`" ? > > The argument is that if someone posts a script that says it does > something innocuous, for example "benchmark showing that X is faster > than Y", people will scan it, see that it looks OK, and run it. They > have a reasonable expectation that it's not a security risk. > > If it requires a benchmarking module from PyPI, they may not > immediately notice that "from __pypi__ import benchmark" opens up a > security risk. On the other hand, being explicitly told to run a > command whose sole purpose is to download and install an external tool > clearly indicates to them that they need to be aware of what's > happening. Likely they will simply do so and it's no big deal. But in > certain environments they may have to pause and possibly even check > with their security team as to whether that tool has been approved. > > It's not about "making it less usable", it's about ensuring that the > implications are clear - explicit is better than implicit, in effect. > Which is a particularly important principle when security risks such > as "downloading arbitrary code from the internet" is involved. > > So it should be something like from unsafe.__pip__ import benchmark Where unsafe is the hypothetical namespace in which exec(), eval() and subprocess.run() would have reside given your concerns. Elazar
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
