« May 2004 | Main | August 2004 »

June 24, 2004

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 ()

June 18, 2004

I was reading this really neat article on DRM, (it's here), and something occured to me. The problem with DRM is this: People are stupid.

It never occurred to the Napstroids that no, there really is a difference between making a mix tape or CD for a friend or two, and, via P2P, effectively making an infinite number of CDs for an infinite number of people in a trice. RIAA may not have liked tapes, or CD burners, but face it, they weren't really being hurt by it either.

I hear the flames starting...shut up, I'm not done.

RIAA was stupid too, hell is stupid. It never occured to them that people would notice something. Like how the quality of the stuff on CD hasn't gone up in over 20 years. Oh, they have nicer players, but that's just some minor oversampling and skip protection, along with digital studios. But it's still 44.1KHz, and 16 bits, and it's still flaccid. Yes. CD audio is flaccid. As flaccid as Janet's right boob. Deal. They never thought that anyone would realize...If I can buy CD blanks for a quarter a pop, and I just read about a monster royalty being two dollars a disc, why did that Jet CD cost me damned near twenty dollars? Face it, other than the occasional pretty packaging, I haven't seen a real improvement in CDs in the last 20 years. The packaging still sucks too.

The problem isn't hordes of Shawn Fannings, out to get the simple, honest, Amish-like folk at RIAA. It's that buying a CD makes you feel like you just got boned in the butt by a concertina wire - wrapped dildo. The big Lexington Steele model. People aren't pirating music because they're evil. They're pirating because they get treated like dirt at every stage of the game. If you treat your customers like dirt, what do you expect?

This is why the DVD biz is so much better.

On the couch next to me is a legally bought copy of “Pirates of the Carribean”. Cost at the Nebraska Furniture Mart? $25.00US. About the same as a dual - disc CD.

Now, let's see...the sound quality on the DVD is so much better than the CD, that you cannot compare. It's better than Vinyl. CD audio sucks ass. It's decent enough I suppose...for twenty years ago. For today? Tin cans and string man, tin cans and string.

(Oh stfu about MP3 or AAC. I know that's worse, but it's more portable, and convenient. Besides, for The Donnas, you need a big dynamic range?)

I get 5.1 surround with THX features. Neat. What do I get on the CD? Why, stereo. Ooooh...and that's only what, 50+ years old in popular use? Why isn't that on CDs? Who wouldn't want to feel like they're on stage with Stevie Ray Vaughan with 5.1 sound? Hell, most car systems have enough speakers. Why hasn't audio progressed? Hell, if you count the death of Quadraphonic in the 70s, it's gotten worse.

So right now, based on audio only, the DVD wins. By a dimension. Literally. The packaging is very nice. Lush colors, textures. A case that is easy to hold, and shelve. Why can't CDs just use DVD cases? They're the SAME SIZE! Oh wait, that might make CDs pleasant to buy. Silly me.

The disks are packaged in a way that makes them easy to get to. True, some DVD cases are put together by refugees from Night of 1000 corpses, but those are the exception, not the rule. So far, quite pleasant.

Now, lets look at content. The original movie: two hours and 23 minutes. This twenty five dollars, that will at most, buy me maybe two hours and 40 minutes of nasty CD audio gives me...something like 12 hours of stuff. It links to the Internet. It's like a treasure trove, (how appropriate here) of coolness. Got a high-end TV? No problem, the DVD has some high-quality video for that toy. I can spend over half a day and be doing something new every minute, and if I have the hardware, damned near replicate the theater experience, (I say nearly, since I don't have to deal with inappropriatly - aged kids, loud bungholes or cell phones. So I don't completely replicate the theatre experience. Oh well, I suppose I'll just have to deal somehow.) for the same $25 that keeps me busy with CDs for just under three hours, and it's the same busy I could have gotten in 1983!

But suppose I didn't see this fine example of pirate-y coolness. What if I'm not sure I want to buy it? No prob, hi-ho, hi-ho, to Blockbuster I go. I'll spend a five, and watch tonight, hi-ho, hi-hohi-hohi-ho. I can rent the movie for a couple of days, and watch it before I buy it. Not at some dipwad “listening station”. But at home. In my underroos, drinking bourbon, and farting when someone on screen opens their mouth without saying anything. In whatever fashion that defines movie-watching comfort for me.

In other words, it's pretty damned nice, the whole renting movies thing.

Buying music sucks ass, with one real exception. (Well, two, but I'm not telling you where God's used LP store is.)

The iTunes Music Store, aka iTMS. (No url, if you don't have iTunes, it will do you no good, and if you do, you don't need it.) I can go in, search, find (or not) buy my crack...er...music...and get the fuck out, FAST. No figuring out where I can play song a vs. song b. In out, wham-bam-gimme my music. Yeah, it has DRM. Boo-hoo. But it's kind of a lame, easily dealt with DRM.

So it's like a titty twister.

Now, if you've never had a titty twister, heh...ask a male friend, I'm sure one will oblige...sucker. But anyway, if that's the worst you've ever had, it hurts...pretty bad. But if you've just gotten your rectum reamed by RIAA's Razor - Bladed Dildo of Doom for the umpteenth time, then that titty twister seems pretty nice. And face it, Steve Jobs is a bit of a hippy, and a vegan, so it's not like he's going for the uber, purple nurple-dear-god-I'll-blow-you-if-you-stop-this-torture-quality twist. More like a “OW!...hey, stop that” kind of twist.

So yeah DRM sucks, but the iTMS is like American Democracy. It sucks so bad, except that it's better than everything else.

As long as the MPAA treats me like it has, I'll buy me some DVDs and not bother copying them. Why should I, I get my money's worth, there's no incentive to spend time and space ripping DVDs.

But RIAA? Man, they make it so you cackle with joy when you pirate music.

Maybe when they stop being stupid, they'll see that trend reverse. Don't bet on it.

| Comments () | TrackBacks (1)