Just a Thought...

I’ve heard of all the great hype about git. If you still don’t know what git is, it’s a distributed version control system. Essentially, everyone has their own private repository and theoretically they happily push changes to each other until the final desired result exists. So who’s jumped to the Git world? Let’s see, you have the Linux kernel team, Rails, several JavaScript and CSS libraries, etc. Honestly, I believe that the real benefit comes from github than from the library itself.

So why am I not a fan? Either I’m a Luddite or I’m old fashioned. One of the biggest problems I have is that we are brought back to the days where everyone needs a SSH account to commit code. CVS had the same mechanism, since it was all file based. Sure you can manage accounts using the SSH public key, which is pretty secure, but I’d rather not have an account I can access a machine with. One of the big selling points for Subversion (now an Apache Software Foundation project) is the fact it could be hosted through Apache’s web server. That means I can use all the different authentication schemes associated with HTTPS or basic authentication. If I want to require public keys, great. If I use LDAP, even better.

The problem with hearkening back to SSH is the fact that some draconian firewalls not only block the SSH port, they also block SSH tunneling. So that SSH tunnel you set up to talk to github? Useless. In turn, this means that collaborating with other users on github is also out. If git operated more like Subversion in this case, I’d have a lot less to say about it.

Currently, the only place I can use git is at home. At home I have very limited time. If you can’t get to your remote repository, what use is the tool?

The idea of using the OpenID provider protocol as an authentication wrapper has been proven by Simon Willison . The concept is not without merit, because not everything is web enabled, but being able to authenticate with your OpenID would be really nice. Again, its the concept of one ID, protected by either you or someone you trust. It’s just not practical in every situation.

Case and point would be integration with subversion. Subversion is a version control system that supports the DAV protocol with some extensions. It means you can use a web front end to look at your repository. It’s what I use both professionally and personally. Most repositories are protected with a combination of SSL and basic authentication. Sure you can do PKI, but that’s a pain and just not practical for open source projects. It has the basic problem of sole sourcing your identities. The basic authentication scheme works well for the command line because the response is just plain text:

> svn co http://d-haven.org/svn/open/trunk/actionpack

User name: bloritsch
Password: *********

The problem with OpenID is that it is not uncommon for the authentication server (your OpenID provider) to provide some sort of HTML for you to do something to let them know it’s really you. The attached image shows roughly what happens from a user’s perspective (minus a few details) with the OpenID protocol. It’s the challenge screen that gets in the way of using OpenID for the command line. The idea of popping up a screen or incorporating a text HTML browser into subversion is a bit ridiculous. It drops the usability. Note: I also left out the “grant permissions” to the client screen—another wrinkle in the system.

But, let’s assume for a moment that we can create a different authentication system to ensure a user is who they say they are. Let’s also assume for a moment that we can use the user’s OpenID as the user name in this authentication scheme. In essence, “bloritsch.d-haven.org” represents my login ID in either system. All that would be necessary for the web interface would be to use the OpenID protocol trappings around that authentication system.

Of course, why bother with the whole mess in the first place? After all you would have to write some plugins for the server side and client side of things, etc. Well, anyone who does software development has to work with their clients somehow. Many times it means letting them have access to your repository, or at least a portion of it. If the identity management is fairly uniform, it’s easier to integrate all the pieces together. By working on an authentication standard that compliments the OpenID platform (instead of replacing it), it will open up the gates for its adoption. Even more so if it solves the problem of using the “basic authentication” issue. If no passwords are sent, plain text or not, it makes it more difficult for someone to intercept the proof of your identity. Anyway, I’ve got some ideas on it, but no funding or free time. We’ll see how long and when/if it will see the light of day.