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.

Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to