Congratulations to Leslie Lamport, winner of the 2013 Turing Award

"Lamport's practical and widely used algorithms and tools have applications in security, cloud computing, embedded systems and database systems as well as mission-critical computer systems that rely on secure information sharing and interoperability to prevent failure."

Many probably think of him mainly as the initial developer of LaTeX, for which I am often personally grateful, but his contributions go far beyond this. Have a look at 

http://amturing.acm.org/lamport and

https://research.microsoft.com/en-us/um/people/lamport/pubs/pubs.html

and form your own conclusions.

During the Ballmer era of Microsoft, there was much heat and noise related to claims that Linux could not innovate. Yet Turing award winners associated with Microsoft were a bit thin on the ground. Not absent: Charles P. Thacker won in 2009, and one of his many accomplishments was helping to establish Microsoft Research Cambridge in Cambridge, England.

Those days are hopefully behind us; it was mostly strategic corporate marketing noise. Microsoft has been been funding his work, by the simple means of employing him, since 2001. Microsoft deserves our thanks as well.

Update: I didn't consider (but should have) that Microsoft would publicize this. That is probably Rule #1 about having a future Turing Award winner on staff, for better than than a dozen years before the award. Everyone involved gets bragging rights for their part in what has always been a demonstrably great hire, the wisdom of which is now getting much wider recognition. Microsoft is justifiably proud. The following video is worth a watch.

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.