I’m not sure if it is the ﬁrst signed third-party application to take advantage of Mac OS X Leopard’s new code signing feature. However, it’s at least the ﬁrst one I’ve seen publicly.
The release notes for Fetch 5.3 show a raft of updates for the little niceties of Leopard. Put Automator actions under the “Internet” category? Check. Prevent Time Machine backups of Fetch’s cache? Check. Support the new application level ﬁrewall (ALF)? Check. Make the appearance match Leopard’s uniﬁed style? Check. And so on.
According to the AppleScript Overview which was freshly revised for Leopard, the AppleScript Utility is scriptable and now lets you enable GUI Scripting. I think this means — although I haven’t conﬁrmed it personally yet — that this is the ﬁrst scriptable way to enable GUI Scripting.
I’ve spent a small amount of time trying to enable it other ways in the past — including the use of the `defaults` tool — and been stymied. I’m not sure when the last time I tried was, or which version of Mac OS X. Nonetheless, a scriptable way to enable GUI Scripting is welcome.
Despite my concerns that GUI Scripting could be a source of security problems — from the perspective of a social engineering attack — there are already many other potential ways to script or automate applications for social engineering mischief. On the plus side, systems administrators and others who need GUI Scripting on or oﬀ, even for just a short time, should have an easier time enabling or disabling it on computers thanks to this change.
Hm. They actually tell you what’s new in Leopard — from a Mac OS X developer perspective, anyway — in the release notes section of the ADC Reference Library.
Who would have guessed? I think I missed this for Tiger. And, AFAIK, it wasn’t available at all for any previous version of Mac OS X. ’Twas a shame, quite a shame.
(I’ve always missed John Montbriand’s old overviews of the Mac OS classic releases; they were a treasure trove, relatively speaking, of information. Even for sys admins.)
Rands In Repose: The Nerd Handbook. The only response I have is: so true, so true.
Now, what were you just saying?
[Via Daring Fireball.]
Last week, I found and installed the Drupal Bad Behavior module. It’s been remarkable to see it working; in only one week of operation, it’s already logged 98 pages of events — at 23 items per page. That’s 2254 likely bots blocked!
In order to install the module, I had to ﬁnd the latest patch/version — one that would work with the current Bad Behavior library — on the Drupal site and install it in my modules directory. I then had to install the Bad Behavior PHP library inside the the new module’s folder. Although this was a little tricky, it certainly feels worth it.
In reading the man page for the updated
installer utility in Leopard, it looks like it oﬀers the equivalent of “answer ﬁles” on Windows. This sounds like a big improvement, especially for systems administrators who want to automate the installation of packages on Mac OS X.
The “install choice change XML ﬁle” can be used to apply changes to the default option in an installer package. This uses the
The installer can also show the defaults as well as the result after applying a choice changes XML ﬁle to them. Use the
-showChoicesXML to ﬁnd the choices and
-showChoicesAfterApplyingChangesXML to see the outcome of choice changes, respectively.
For what it’s worth, the
-query ﬂags are also new and have functions that I don’t recognize from Tiger, comparing the two man pages.
Anyway, the install choices sound like a “win” — even just to get reliable, reproducible Radmind transcripts, if you’re into that sort of thing. Imagine creating an installer choice change ﬁle for a package you install/update all the time — the system software itself, and the Apple Xcode Developer Tools, both spring to mind. Whether you’re creating install choice change ﬁles for bulk installation or just automation of your build process, it sounds as if this new capability should be really helpful.
TidBITS: Apple to Allow Virtualization of Leopard — Mac OS X Server, not the workstation version.
This is pretty big news, even though it’s really only the change in EULA right now. It would solve a great many problems in hosting Mac OS X Server if VMWare ESX could run on Apple hardware. If you could make Xserves part of an ESX cluster, and you could limit the Mac OS X Server to running on just the Apple hardware in that cluster … that would be very good. But this is all wishful thinking and speculation on my part.
I checked on the version of xar that ships with Mac OS X 10.5 Leopard, and I was dismayed to ﬁnd it’s 1.4. Xar is new to Leopard, but it’s got a much older version that dates back to January 10, 2007.
$ xar --version
The latest version, 1.5.1, is from June 10. Version 1.5 is from May 14. The beneﬁt of the newer versions is that they have ﬁxed ﬂaws and passed the Backup Bouncer test. Leopard’s bundled version is apparently too old to incorporate the ﬁxes that put xar over the top on the test. That’s too bad. I was — and am — looking forward to its possible use for backups of all the kinds of data that can sit in the Leopard ﬁlesystem.
I also found the man pages for process sandboxing in Leopard; it’s found under “sandbox”:
$ man sandbox
I found the man page for code signing in Leopard; it’s found under “codesign”:
$ man codesign
Update: It’s worth noting that Apple has released the Code Signing Guide to document this feature further, from a developer perspective.