There Are No 'Safe' Languages

In posts like http://fubarnorthwest.blogspot.com/2013/10/choosing-python-over-r.html I did a bit of Python advocacy. I didn't cover half of it; R has some very strange, by modern standards, naming conventions, which makes learning R harder than it should be. But what I really wanted to mention is that a few people who know me and my focus on security, ran into the Googles. There are a few claims out there about Python being a 'safe' language, and they somehow assumed that I had blessed Python.

No. Whatever 'safety' posts they read were likely about buffer overflows, which Python will indeed protect you from, until the language implementation itself has a problem with buffer overflows. See http://bugs.python.org/issue20246. They are rare, but when they do occur, the problem reduces to keeping your Python system patched, with the attendant patch verification, propagation, etc., problems that you would expect, somewhat mitigated by Python having nice testing frameworks. But this is mostly just a bog-standard IT patch-mangement problem.

Nor is that the end of the story. The native Python data persistence mechanism (pickle) carries the same risk as any persistence mechanism: how is it protected between write and read? There are also the usual tribe of cut-and-paste folk who have no idea what they are doing, but have an immediate need to make something work. Mistakenly fumbling uuid1 instead of uuid4 into your code, because you did not read the docs, is going to be a problem if leaking a network address is a serious flaw.

There are no circumstances that would allow me to 'bless' a language, in a security context. The best that can be said is that some are safer than others.