November 2009

Alice verifies Bob by phone.

Sometimes I have to trade information with people I’ve never met. I know who they are, in the sense that I know what they’re working on, why we’re collaborating, etc. But I wouldn’t recognize their face or voice. Occasionally, the information we’re trading is sensitive — news of a software security vulnerability, for example, or the address of a mutual collaborator who cares about privacy.

How can you know that the person you’re talking to is the person you think they are? You can send them encrypted messages, but you still need to verify that you’re using the right encryption key. So you call them up or find them in an online chat room and verify the key fingerprint… but how do you know that the person you’re verifying with is the right person and not some man-in-the-middle attacker?

It may all sound a bit spy-vs-spy, but anyone who works on widely-used open source software can find themselves in this situation. It’s happened to me more than once.

The solution I use is something I call the Instant Answer Protocol:

Alice wants to verify that the person she’s talking to in real-time is Bob. She digs up a few random facts about Bob on the Internet, or by talking to someone they both know, then phones or chats online with Bob and asks him about those facts. In the absence of a very dedicated impersonator, only Bob would be able to instantaneously answer unexpected questions about himself, so his identity would then be established to a high degree of certainty. After that, she can voice-verify Bob’s encryption key fingerprint or do whatever else she needs to do.

Such a check still wouldn’t protect against a determined and well-funded imposter… but then, how can you even be sure it’s you reading this?

I’ve used the protocol several times. I’ve never caught my interlocutor trying to fake someone else’s identity, but it gave me peace of mind anyway.

Obviously, this is a very old protocol. It predates the Internet, and probably literacy itself. Does anyone know if this protocol already has a name in cryptography circles?

CollabNet   Subversion   Apache Software Foundation

The Subversion project has applied to become part of the Apache Software Foundation — an application we all expect to suceed swimmingly, given that Subversion has been operating more or less along ASF guidelines for years anyway, and includes a number of ASF members and officers among its developers.

The move isn’t that much of a change, actually. The web pages and repository hosting may move over to the ASF, but the developers are still the same, as is the participation of Subversion’s long-time primary corporate sponsor, CollabNet.

The main effect of the move will be to free up some developer time that had gone to maintaining the separate non-profit Subversion Corporation. It just makes more sense to handle Subversion’s non-profit needs as part of an established entity that’s already been doing it for ten years. You can go nuts trying to deal with all the tax and legal stuff… why not let the ASF handle it? 🙂

I have to admit to a vaguely warm and fuzzy feeling about it: the ASF is a place for mature projects that intend to be around for a long time, independently of what any individual developer does. Their policies are aimed at ensuring the long-term health of the development communities, and they have a lot of practice at working with corporate sponsors of development already. Ben Collins-Sussman put it better than I could: “Collabnet has always been the main supplier of ‘human capital’ for the project in terms of full-time programmers writing code, and that’s not going to change as far as I can see. Collabnet deserves huge kudos for the massive financial investment (and risk) in funding this project for nearly 10 years, and it seems clear they’re going to continue to be the ‘center’ of project direction and corporate support for years to come. And this pattern isn’t uncommon either: the Apache HTTPD Server itself is mostly made up of committers working on behalf of interested corporations.”

I haven’t made any commits to Subversion in a long time — too long, but I’ve got a busy new job and a non-profit on the side, so my time is mostly spoken for lately. Although I still read the Subversion mailing lists and occasionally chime in with (increasingly uninformed) opinions, more and more I’m becoming just a regular user. Subversion has had several releases since I stopped doing development work on it; I’ve upgraded each time and it’s just been rock solid, a pleasant experience all around. Exactly the way version control should be.