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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4