« 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:
- Security
- 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 volumeis 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.
- 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.
- 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.
- 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.
- 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.
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
- Private key left
- Public key left
So, even though I have a lot of keys, Keychain scripting cannot see them.
I remove Private key and Certificates:
- Public key left
Still no love from Keychain Scripting.
I remove all three:
- None left
BOOYAH, I get some love from Keychain Scripting!
I remove only Private and Public keys:
- Certificates Left
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
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
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.
Posted by John C. Welch at 12:49 | Permalink
Comments
This article just saved me what would probably have been a huge amount of time - thanks! I was actually researching a problem that turned out to be due to the reference to a keychain as keychain "name" (Jaguar) vs. keychain "name.keychain" (Panther), but it led me to test another script that worked great last month but has indeed now mysteriously stopped working (since I received a bunch of certs in the meantime).
Posted by: David Ravetti | March 25, 2005 3:47 PM
Thanks. This posting saved me a lot of trouble. It's pretty irresponsible that this still hasn't been fixed.
Posted by: Sean | March 27, 2005 1:16 AM
