MadMode

A couple months ago, I inherited some Java code and took on the task of fixing a bug in it. The bug turned out to be a consequence of a silent failure; eek! And there were precious few tests and no way to test the parts without being connected to LDAP servers and SQL databases and such. This started me on an exploration of current best practices in testing. And since the job of this code was policy enforcement around patient data, I could finally justify getting my hands dirty with capability-based security. I discovered, as many others have, that both testability and security are well served by some of the same basic object-oriented techniques.

Dependency injection frameworks always smelled like overkill to me, but after watching Miško Hevery on testability, I was convinced. If you're in the mood for text rather than video, see his Guide: Writing Testable Code. Basically, instead of having some policy enforcement object constructor call an LDAP connection constructor, the policy enforcement object takes the LDAP connection as a constructor argument. "Don't call us; we'll call you" is a handy mnemonic. This lets you substitute a mock LDAP connection for testing.

It also forms patterns of cooperation without vulnerability.

For example, take a look at the simple money example in E and the underlying sealer/unsealer pattern.

I have been using these as an exercise to explore some of the recent programming language developments:

• money.coffee in August
• sealing.py in October
• money.dart November 10
• money.scala November 11

The coffeescript translation seems completely natural, to me. Given the right static scope (i.e. without most of the JavaScript standard library), I think it has the same security properties as the E version. And the E idioms seemed to translate quite directly.

Python has not only the API authority issues, but also untold introspection loopholes. Plus, I had to kludge around read-only closures and no-assignment-in-lambdas; and while simulating E's method suite idiom is not too ugly, tools like pyflakes don't recognize the results.

Dart is a big disappointment. Everywhere else I look, Google is pushing capability security. But Dart lacks nested classes, so translating E method suites results in something that is only vaguely recognizable, let alone comprehensible.

Scala works reasonably well. The Java implementation of sealing relies more on  strong typing than the object graph for rights amplification; I might want to think that over some more. Also, It's a little boring to spell out the types. I might have to try it in Haskell. But on the other hand, as Brendan Eich observes:

Dynamic languages are popular in large part because programmers can keep types latent in the code, with type checking done imperfectly (yet often more quickly and expressively) in the programmers’ heads and unit tests, and therefore programmers can do more with less code writing in a dynamic language than they could using a static language.

The balance between static and dynamic languages also shows up in development tools. I had the eclipse with the Joe-E verifier, maven, and mercurial working all together at home one evening. The code really does just about write itself at that point. But when I tried to reproduce it at work, I got so frustrated that I retreated to emacs and python and looking up function arguments manually. The python version of the project has gotten complex enough that I'm starting to miss some of the whole-program consistency that Java tools give, but I'm getting by with a bottom-up approach: flymake, doctest, and the like.