-----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

Reply via email to