ronin coder

…for voting! (Well, for trying to convince people to vote, anyway.)

I am currently being bitten by the iPhone NDA, despite not ever having agreed to be bound by it. I’ve had reports from people who are working on iPhone apps that certain websites appear to render incorrectly on their systems. They have sent screenshots to prove it.

However, checking the same site, from the same OS X build and Safari release version, I see only properly-arranged columns. After eliminating basically every other likely cause, I am left with the suspicion that the iPhone SDK has somehow modified or extended WebKit.framework, causing even the system-packaged Safari to render pages differently.

Unfortunately, I can’t really fix it. I don’t have the iPhone SDK, and won’t “sign” Apple’s NDA to get a copy just to troubleshoot CSS issues that will only affect perhaps a few dozen visitors. (The intersection of iPhone developers and grassroots political volunteers seems not-so-huge.) Unfortunately, I also can’t ask anyone I know doing iPhone development to help, since any information they disclosed could potentially violate the NDA to which they have agreed.

This does not make Lennon a happy little coder.

Update: A little bird told me that their system, which also had the iPhone SDK installed, does render the page correctly. So much for that solution. I am still irritated that the NDA pretty much ties my hands when it comes to more fine-grained troubleshooting.

Rails has a fun (well, okay, kinda crippled and lame but still interesting) piece of infrastructure called ActiveResource. It basically lets you glue domain model objects from multiple Rails apps together via REST, and it actually works pretty well if you’re using vanilla ActiveRecord models and/or don’t mind doing your own XML serialization logic.

Unfortunately, the authors of said module appear to either a) not understand how SSL works, b) not really care or c) both. As implemented currently, the ActiveResource HTTP client will blindly accept any certificate presented to it, no matter who signed it. This is a Big Deal, at least for any apps using ARes across the firewall.

For those who don’t already grok SSL, here’s a shortened version:

Each site that wants to use SSL to protect traffic first generates a private key (which must be kept secret). They use that key to generate a public key encoded in a certificate-signing request (CSR), and then send that CSR to a certificate authority (CA). The CA signs the CSR using their own private key, and returns it as a finished SSL certificate.

At this point, the certificate serves two purposes: it provides a public key for others to use when encrypting traffic to and from the server, and it asserts that the entity bearing the certificate is the one named in its description. It is the responsibility of the CA to make sure that certificates are only issued to the right organization, which basically means that certificate authorities must themselves be very trustworthy indeed.

Clients connecting to a server using SSL ask for a copy of that server’s certificate before sending any sensitive data. Since the certificate is unforgeably signed by a single CA, the client can decide whether to trust the signing CA. If they do, they can then be reasonably safe in the assumption that the entity identified as the bearer of the certificate is who they say they are. (In most cases, this “entity” will be a simple hostname, like ‘mail.google.com’.)

If, on the other hand, the client does not trust the signing authority, there are two reasonable paths: it can allow the user to temporarily accept the certificate, or just reject the connection entirely. The former is a somewhat-common case for interactive applications like web browsers, but the latter usually makes more sense in a backend-systems case, since it’s better to fall back on secure defaults.

Now, the ActiveResource code takes yet another approach, which I consider unsound: it simply ignores the certificate error and continues with the connection as planned. This unfortunately means that anyone at all could claim to be a popular web service provider (think Twitter, or Campfire, or any of a thousand other popular APIs), and ActiveResource clients would simply accept that assertion and pass along user data without even logging an error.

Normally, I wouldn’t disclose a security issue like this on my blog before making every effort to make sure that the project maintainers had a chance to evaluate and patch the issue, but the current ActiveResource implementation actually goes out of its way to squelch any certificate-related errors. Given that, I suspect that this is really more a case of just needing to identify where ActiveResource is an appropriate solution.

Ignoring certificate verification may be fine and dandy for quick development work, and even within a trusted server subnet, but could easily burn you out on the wild world of the ‘net.

I’ve submitted a ticket and patch, so we’ll see what happens.

I’ve had a few people ask me to post this since I twittered about it a couple of months back. Basically, it’s just a trivial little Jabber bot which notifies a list of interested people whenever there’s a commit to a watched subversion repository. (Of course, admitting amongst Ruby people that you use Subversion in this day and age is kind of like confessing to a love for MS-DOS, but I consider it a personal victory to have the folks at work using any sort of SCM.)

The notifier has two pieces: a persistent process, which connects to your Jabber server and listens for requests over DRb on a loopback socket, and the post-commit hook, which you install in your Subversion repository, and which gets executed by Subversion after each commit goes through. The only configuration needed is to pass the JID and password for the sending Jabber account to the notifier (which is accomplished via command-line args when you start it), and providing a list of JIDs to be notified on commit, which is accomplished via a whitespace-delimited plaintext file in the repository hooks directory.

(For those of you who haven’t checked out Subversion’s “hook” support, I highly recommend checking out the appropriate chapter in the Red Book. It’s a pretty nice little trick to have up your sleeve, and something tells me similar tricks are possible with Git repositories as well…)

Here’s the code, in its entirety. First, the post-commit hook:

#!/usr/bin/ruby
# post-commit hook; install in SVN_ROOT/hooks/
# give it a file called 'svn-notify' (in the same dir) containing one JID per line

require 'drb'

NOTIFY = File.read("#{File.dirname(__FILE__)}/svn-notify").split

REPOS = ARGV.shift
REV = ARGV.shift

DRb.start_service

log_msg = `svnlook --revision "#{REV}" log "#{REPOS}"`.chomp
commit_by = `svnlook --revision "#{REV}" author "#{REPOS}"`.chomp

project = File.split(REPOS).last
person = commit_by.split('@').first

msg = "New commit (r#{REV}) to `#{project}' by `#{person}': #{log_msg}"

bot = DRbObject.new nil, 'druby://localhost:99843'
bot.deliver(NOTIFY, msg)

And last but not least, the entire Jabber notifier:

#!/usr/bin/ruby
# Jabber commit notifier
# Run from wherever you like, after installing the 'jabber-simple' gem.
# Pass it the JID and password for your sending user as command-line args.

require 'drb'
require 'rubygems'
require 'xmpp4r-simple'

JID = ARGV.shift
PWD = ARGV.shift || gets.chomp

if JID.nil? or (PWD.nil? or PWD.empty?)
  STDERR.puts("usage: #{__FILE__} 
 (password can be on stdin, too)")
  exit 1
end

class RemoteBot
  include DRbUndumped

  def initialize(bot)
    @bot = bot
  end

  def deliver(to, msg)
    @bot.deliver(to, msg)
    return true
  end
end

xmpp = Jabber::Simple.new(JID, PWD)

DRb.start_service 'druby://localhost:99843', RemoteBot.new(xmpp)
DRb.thread.join

Voila! Now you can compete with your co-workers to see who can spam the other with more (and more creative!) commit messages.