« Why DVDs get bought and CDs don't, and why I love the iTunes Music Store. | Main | Real Networks HQ is now Spin City »

Rick Schaut, of the Microsoft Mac BU has written an excellent article on how hard it can be to track down a bug. However, lest one thinks that only big applications like Word can be that hard to troubleshoot, let me set you straight. Even relatively small applications can have bugs that are amazingly hard to track down. Even something as small as the Keychain, and Keychain Scripting.

One of the problems with AppleScript is dealing with login credentials. For example, when you are wanting to mount an AFP volume, you can always use the traditional mount volume "afp://password:username@dnsname" schtick. There are two real problems with this:

1. Security
2. Flexibility

With regard to security, the login credentials are right there in the script. Any goober with a copy of script editor can see them. If you make it run only, you make it a little harder to hack, but not by much. On the flexibility front, everything is hard coded. You can't change the username or password without redoing code.

The keychain made this better, although, perhaps not simpler. Let's look at our original example:

mount volume "afp://password:username@dnsname" Simple, easy to understand. Since mount volume is in Standard Additions, we don't even need a tell block. One statement, and it's the magical world of network automation. Whee!

Now, let's look at the Keychain'd version, and we'll say that the name of the key is "testkey":

tell application "Keychain Scripting"
     set theKeychain to the current keychain
     set theKey to AppleShare key 1 of theKeychain --this is oversimplified for clarity's sake
     set theKeyAddress to the address of theKey
     set theKeyVolume to the volume of theKey
     set theKeyUserID to the account of theKey
     set theKeyPassword to the password of theKey
end tell

set theServerURL to "afp://" & theKeyAddress & "/" & theKeyVolume

mount volume theServerURL as user name theKeyUserID with password theKeyPassword

so it's a little more complex, but lets look at what we get from that complexity.

1. We don't hardcode the password into the script. that's a MAJOR plus. Because even if you make a script read-only, there are ways of getting the information out of it.
2. The script is far more flexible. For example, if you have many users that need different levels of access to a share, this script can work for them unchanged. You only need to change the user ID and password information in their Keychain. Since none of this is hardcoded, you get all of it just by asking for it. The only thing that needs to stay the same is the name of the key. Heck, you can even point different users at different servers, all with the same script if you need to.
3. If we wanted to, we could use an Internet key instead of an AppleShare key, and not have to hardcode the protocol. So, if you needed to move people from an AFP server to an SMB server, or vice-versa, you could, and not have to change the mount script.
4. Because the password is never typed, it's far harder to sniff out. There are ways, it's not encrypted, and if you're using this across machines on a network, someone with a packet sniffer can grab it without a lot of trouble, but it's still more secure and flexible than hardcoding the login info in the script.

So by using the keychain for things that require a password, we gain a lot of flexibility and security without a hideous amount of extra work.

As you may be able to tell, I love Keychain Scripting. So when it broke in Panther, I was stunned. It just died. I couldn't get a list of keys from my keychain at all. I could get info from every other keychain, but not mine. Now, if I had only had a few items, then I just would have moved them into the new Panther default keychain, login.keychain. However, I have almost 430 items in my Keychain, and moving/copying items between keychains is hideously tedious, for good reasons. As it turns out, that wouldn't have fixed this bug anyway.

So I file the bug, and the reaction I get from Apple is "huh? It works great!". My response: "The hell it does, it's broke."

So we do the keychain repair thing testing code, etc. My keychain works with everything BUT AppleScript. Every other keychain works with AppleScript. So in spite of denials from Apple, I have a sneaking feeling that something changed in the keychain file format between Jaguar and Panther.

As it turns out, I was completely wrong on this, but there was a very bizarre bug that would take time to discover.

Fast - Forward a few months.

I start seeing more people hitting this bug. My reaction was Thank GOD, it's not just me anymore! So everyone starts going around, and finally, Paul Berkowitz, Scripting Genius, (He's terribly modest, but he's a genius. Really. ) starts asking if the people with this problem have SSL certificates in their keychains.

Bingo. That's the bug. Please allow me to show you the specific path I took to find the exact problem:

I ran a series of tests with the following code:

tell application "Keychain Scripting"
     set theKeychains to every keychain
     set theKeychain to item 1 of theKeychains
     set theKeys to every key of theKeychain
end tell

That should create a list of every key in my default keychain. But it didn't.

There were three types of SSL certs in my default keychain:

• Certificate
• Private key
• Public key

I remove Certificates only:

• Private key left
• Public key left

Result: empty list, 392 keys in the keychain.

So, even though I have a lot of keys, Keychain scripting cannot see them.

I remove Private key and Certificates:

• Public key left

Result: empty list, 392 keys in the keychain.

Still no love from Keychain Scripting.

I remove all three:

• None left

Result: 392 items in the list, 392 keys in the keychain.

BOOYAH, I get some love from Keychain Scripting!

I remove only Private and Public keys:

• Certificates Left

Result: 392 items in the list, *399* keys in the keychain. Keychain scripting seems to be blind to certificates, so they don't exist.

Hmm...so that's a bug too, but not the one I'm looking for. Annoying, but still at least seeing things in the keychain.

I remove only Public keys:

• Certificates left
• Private keys left

Result: empty list, 392 keys in the keychain

Getting closer. It's not just certificates, and it's not just public keys. Nor is it private AND public keys. It's definitely public keys by themselves. So the only thing left to see is if it's private keys by themselves.

I remove only public keys and certificates:

• private keys left

Result: empty list, 392 keys in the keychain

So it seems there are two bugs here, one major, one minor:

The major bug:

     *ANY* SSL key, public or private somehow screws Keychain scripting into the ground, and prevents it from getting a count of ANY keys in any keychain with public or private SSL keys. This is bad.

The minor bug:

     SSL certificate entries just don't exist to Keychain Scripting. They don't cause any other problems, they just don't exist.

And that, ladies and gentlemen, is why I was having such agony with Keychain Scripting in Panther.

But why did I see it so early?

I worked at MIT when Panther came out. MIT makes heavy use of SSL everywhere. They live and die by Kerberos and SSL. So I was using certs in the Keychain and with Safari before most people were. So, logically, I would see it first, or at least before everyone else. In fact, I had certs in my keychain before Panther. So obviously this bug wasn't in Jaguar.

Why did it take so long to find out? Because nothing changed with Panther that would tell me this. There was no error message, no crashing. Just...no keys. A silent failure. Damnably hard to find.

So even if you aren't working on Word, you can still have bugs defy solving for long periods of time.

Comments

Warning for Notes users: The commenting system uses HTML.
I know this will be scary for some of you, especially Notes fans. However, open standards, rah-rah.
If you want to use less-than or greater-than signs, or other similar charachters that HTML reserves,
you'll simply have to learn to do it the HTML way. Luckily, HTML is kind of popular, no matter what
your re-educators have told you, and you can easily find help on the intertubes.