[Python-Dev] What attempts at security should/can Python implement?

[Martin v. Löwis]

Skip Montanaro <skip@pobox.com> writes:

> Now that Guido has rendered impotent any attempts Python did make at
> security, does it make sense to try and figure out what (if
> anything) can be done by the C runtime?

I think Guido's rationale for removing all these features will be
widely misunderstood. Me channeling him: it is not that he believes
that the architectures developed were inherently incapable of
providing security. Instead, he feels that no "expert" for these
matters has reviewed these architecture for flaws, and that the
continuing maintenance of these things isn't going to happen.

If this understanding is correct, then any new approaches will likely
suffer from the same fate. Unless somebody steps forward and says: "I
am a security expert, and I guarantee that this and that feature is
secure (in some documented sense)", then I think he will dislike any
changes that mean to provide security.

So this not a matter of engineering but of authority. Somebody must
take the blame, and Guido doesn't want to be that someone.

> Somebody asked about tainting in the past week in a response to a
> year-old feature request on SF.  Does that fall into this category?
> I've been working my way (slowly) through Kent Beck's "Test-Driven
> Development by Example" and was thinking that adding tainting to
> Python strings might be an interesting application of those ideas
> (for someone wanting to learn by doing), but if tainting won't be of
> any use I'll find something else.

I'm pretty sure that tainting would have to be maintained as a
separately-distributed patch for quite some time (e.g. a tpython
branch). Only if users accept it as secure, and only if the author is
known in the community, and willing to continue maintaining it, and
willing to take all the blame, it could be merged into Python.

Regards,
Martin