On 4 June 2017 at 10:00, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > Is this really much of a security issue? Seems to me that > for someone to exploit it, they would have to inject a > malicious .py file alongside one of my script files. If > they can do that, they can probably do all kinds of bad > things directly.
There are genuine problems with it, which is why we have the -I switch to enable "isolated mode" (where pretty much all per-user settings get ignored). However, just dropping the current directory from sys.path without also disabling those other features (like user site-packages processing and environment variable processing) really doesn't buy you much. So the better answer from a security perspective is PEP 432 and the separate system-python binary (and Eric Snow recently got us started down that path by merging the initial aspects of that PEP as a private development API, so we can adopt the new settings management architecture incrementally before deciding whether or not we want to support it as a public API). So rather than anything security related, the key reasons I'm personally interested in moving towards requiring main-relative imports to be explicit are a matter of making it easier to reason about a piece of code just by reading it, as well as automatically avoiding certain classes of beginner bugs (i.e. essentially the same arguments PEP 328 put forward for the previous switch away from implicit relative imports in package submodules: https://www.python.org/dev/peps/pep-0328/#rationale-for-absolute-imports). Currently, main relative imports look like this: import helper This means that at the point of reading it, you don't know whether "helper" is independently redistributed, or if it's expected to be distributed alongside the main script. By contrast: from . import helper Makes it clear that "helper" isn't a 3rd party thing, it's meant to be distributed alongside the main script, and if it's missing, you don't want to pick up any arbitrary top level module that happens to be called "helper". Reaching a point where we require main relative imports to be written as "from . import helper" also means that a script called "socket.py" could include the statement "import socket" and actually get the standard library's socket module as it expected - the developer of such a script would have to write "from . import socket" in order to reimport the main script as a module. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
