On Mon, Aug 15, 2016 at 9:05 AM, Xavier Combelle <[email protected]> wrote: > I know that some use case makes a use of just using .pyc and not keeping > .py around, for example by not distribute the source file. > But in my vision, this uses case should be solved per opt-in decision > and not as a default. Several opt-in mechanisms could be envisioned: > environment variables, command line switches, special compilation of > .pyc which explicitly ask to not check for the hash.
Of those, only the last one is truly viable - the application developer isn't necessarily the one choosing to make a sourceless module (it could be any library module anywhere in the tree, including the CPython standard library - sometimes that's distributed without .py files, to reduce interpreter on-disk size). So what this would mean is that a sourceless distro is not simply "delete the .py files and stuff keeps working", but "run this script and it'll recompile the .py files to stand-alone .pyc files". As such, I think the idea has merit; but it won't close the backdoor that you mentioned (anyone who wants to make that kind of attack would simply make a file that's marked as stand-alone). That said, though - anyone who can maliciously write to your file system has already won, whether they're writing pyc or py files. The only difference is how easily it's detected. Fully loading and hashing the .py file seems like a paranoia option, and if you want that, just blow away all .pyc files, have your PYTHONPATH point to a read-only file system, and force the interpreter to compile everything fresh every time. How does this interact with the __pycache__ directory? ChrisA _______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
