People familiar with Adobe PostScript will recognize the source of this label misprint.
Everywhere I’ve worked, people believe in them. They’re the ones who clear jams, change toner cartridges, reload the paper trays, and clean up the messy pile of abandoned printouts, and finally they’ve been captured on film. I give you…
I have never been more annoyed at an application’s failure to fail.
We have this service daemon that performs various actions on incoming images. Recently, it’s been crashing at random intervals, leaving behind a core file that tells us precisely what function it segfaulted in, but includes nothing to tell us where the image came from. All we know is that somewhere out on the Internet, there are JPEG images that crash our copy of the IJG JPEG library in jpeg_idct_ifast().
Since this was affecting customer performance, we really wanted to know, so we cranked up the logging on one of the affected thirty-two servers, to capture the incoming request URLs. And it hasn’t crashed since.
Four days of crashes every hour or so, and now nothing. The good news is that our customers are less unhappy. The bad news is that our developers don’t have a test case to code a fix against.
So now I’m trolling the web, looking for corrupt JPEGs. I strongly suspect that the images that caused our problem were intended to exploit holes in a certain other OS, but I can’t be sure until I find some and feed them to our server. Sigh.
Gamer friend Scott just discovered that the reason he was having so much trouble with PCGen under Linux was that the JVM was defaulting to a rather small heap size, effectively thrashing the app into oblivion when he tried to print.
Now, while it’s true that PCGen is as piggy as a perl script when it comes to building complex data structures in memory, it’s still fundamentally a straightforward application, and yet it exceeds the default maximum heap settings. He had plenty of free RAM, gigs of free VM, and here was Sun’s Java, refusing to use any of it unless he relaunched the application with a command-line override. Doing so not only fixed printing, it made the entire application run substantially faster. Feh.
I’d noticed a slowdown with recent versions of PCGen on my Mac as well, but Apple was good enough to compile their JVM with defaults sufficient to at least make it run completely. Sure enough, though, increasing the default heap settings makes it run faster, by eliminating a whole bunch of garbage collection.
In other words, with Java, Sun has managed to replicate the Classic MacOS annoyance of adjusting memory allocation on a per-application basis, and made it cross-platform!
PCGen is still the only major Java app I have any use for on a regular basis, although there’s another one that has recently entered my arsenal of special-purpose tools, Multivalent. I have no use for 99% of its functionality, but it includes robust tools for splitting, merging, imposing, validating, compressing, and uncompressing PDF files, as well as stripping the copy/print/etc limitations from any PDF you can open and read.
There’s another Java application out there that might join the list sometime soon, Dundjinni, but first the manufacturers have to finish porting it from Windows to the Mac…
Last year I posted a reference to Arnold Reinhold’s Diceware page, and included a copy of my favorite passphrase generator, which attempts to generate pronouncable nonsense words.
I’ve always been a big fan of pronounceable nonsense, even in the days when passwords were limited to eight characters, but I think it’s particularly useful for long passphrases. My problem was that it can actually be pretty difficult to get a good nonsense phrase out of the original table. So I made my own.
Now, the instinctive reaction to someone creating their own security tool instead of using one created by an expert is (or ought to be) an anguished cry of “Noooooo, you fooooool!”. This is a special case, though, because the beauty of the Diceware scheme is that the contents of the table don’t actually matter, as long as each cell is unique. You could fill the first column with colors and the rest of the cells with the names of different superheroes, and the resulting passphrases would contain just as much entropy.
So here’s my new favorite method of generating passphrases. Roll three six-sided dice (one to choose a consonant, two more to choose the rest of the syllable), repeat at least ten times, and assemble into a phrase.
| 1 | 2 | 3 | 4 | 5 | 6 | ||
|---|---|---|---|---|---|---|---|
| B | 1 | a | ad | ag | al | an | az |
| K | 2 | e | ed | eg | el | en | ez |
| M | 3 | i | id | ig | il | in | iz |
| P | 4 | o | od | og | ol | on | oz |
| S | 5 | u | ud | ug | ul | un | uz |
| T | 6 | ay | oy | ath | eth | ith | oth |
Update: Sorry if I didn’t make it clear. Split the results up with spaces to create two- or three-syllable “words”.
Also, a word on the relative strength of passphrases. Each syllable contains ~7.75 bits of entropy (log2(666)), so ten syllables produces a 77.5-bit passphrase, which is likely good enough for data that isn’t kept under lock and key 24x7 (e.g. login password on a laptop). See Reinhold’s FAQ on passphrase length for details. Note that the dictionary-based Diceware system requires longer passphrases to get the same strength (5d6 per word versus 6d6 for nonsense syllables).
I hadn’t seen any good spam for a while, even when I indulged my curiosity and looked inside Mail.app’s Junk folder before wiping it clean. This one, however, stood out in the crowd.
Silly me, I didn’t even know the FDIC had an office in Beijing, much less that it was where they hosted their “ATM/Debit/Check Card Protection Program”.
It was, of course, sent to the email address that’s in my WHOIS records, which is not on file with any banking institution I do business with. Not that I’d have fallen for it anyway…
Fun little blog entry documenting the life and death of a bug in Microsoft Word for Mac. A nice reminder of how difficult it can be to predict how your shiny new feature will interact with old code, and, more importantly, why it can take so darn long to fix an “obvious” bug. I’d love to see a similar explanation of Apple’s “can’t use capital U in firmware password” bug.
One thing this story doesn’t touch on is the importance of clear, unique error messages. If Word had actually reported “too many open files” instead of “disk full,” the problem might have been fixed a lot sooner. In one of my own favorite debugging stories, our discovery of the message “oh shit: fState != kParseError” led us directly to one line out of 16,000. It wasn’t clear, but it was at least unique.
This Mac security hole has been all over the web recently. The thing that makes it dangerous is that it’s ridiculously easy to exploit. The thing that makes it annoying is that anyone on the development team should have seen it coming a mile away, especially given the many well-publicized scripting exploits in Windows software.
How did it happen? WebCore. In an effort to produce a common HTML/HTTP library for all applications, functionality that used to be restricted to the Help tool was suddenly embedded in everything that retrieved or displayed web pages. Apple’s pervasive AppleScript support completes the circle.
Ask not what you can do with scriptable applications; ask rather what scriptable applications can do to you…
Update: The official fix is available via Software Update.
Update: You still need to turn off the Open “safe” files after downloading option in Safari, because disk: URLs still work, and mounted disk images can include auto-execute programs. Yes, there are two stupid features in the previous sentence.