-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lie Ryan wrote:
> Tres Seaver wrote: >> I'm not arguing that employees should violate their employers' policies: >> I'm arguing that Python itself shouldn't try to cater to such policies. > > Basically you're saying: Python is designed not to work on such environment. No, I'm saying that it isn't Python's responibility to enable that kind of policy. If it happens to be good *for Python* to have a a package installation / upgrade machinery (the real point of the discussion), then it will be up to the paranoid admin to figure out how to disable that feature: it isn't the problem of the Python developers. There are real costs to "batteries included," especially for modules which don't get used much. One such cost is that an unused module tends to bitrot over time; another is that the presence of a module in the stdlib may "shadow" other, better modules / packages which are not in the stdlib. Those costs need to be balanced against the undoubted benefits, when making the choice to add or remove a module from the stdlib. >> Note that I'm not talking about running code pushed on me by malware >> authors, either: I'm talking about "ordinary" software development >> activities like using a script from a cookbook, or using a well-tested >> and supported library, rather than NIH. > > Some companies have /very/ strict policies on running anything on live > server, including scripts you write yourself. The problem is if the > script goes awry, it might disturb the stability or even security of the > server. I understand that such policies exist, and why. However, I don't think their existence is a relevant constraint on the design or implementation of Python. >> Given that the out-of-the-box Python install already has facilities for >> retrieving text over the net and executing that text, the notion of >> "locking down" a machine to include only the bits installed in the stock >> Python install is just "security theatre;" such a machine shouldn't >> have Python installed at all (nor a C compiler, etc.) > > When the server administrator is already freaked out about adding an > script developed by in-house employee, what about adding an external module? An admin who is that paranoid shouldn't be giving people shell access, either: given shell acccess, network connectivity, and the existing stdlib the admin's policy is unenforceable as a technical measure. Even if the user can't create a file anywhere on the filesystem, the interpreter prompt is enough to allow the user to evade the policy. Heck, the *bash* prompt is enough to wreck it, e.g. using "here documents," even without network connectivity. As an aisde: anybody who is installing packages from PyPI on a production box (rather than using an index under their own control) isn't sufficiently paranoid: it can and does happen that people re-upload changed packages to PyPI without changing the version, for instance, not to mention removing older releases. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJuooU+gerLs4ltQ4RAsdnAKCSkKc94bHvHBIrILampl9+Mksz8wCeJSBe +Yl5HVmwQ6StGTcWNmDiSjE= =qGID -----END PGP SIGNATURE----- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
