I’m not sure if it is the first signed third-party application to take advantage of Mac OS X Leopard’s new code signing feature. However, it’s at least the first one I’ve seen publicly.
[Bad link] 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 firewall (ALF)? Check. Make the appearance match Leopard’s unified style? Check. And so on.
According to the
[Bad link] 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 confirmed it personally yet — that this is the first 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 off, 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
[Bad link] — 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
[Bad link]. 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 find the
[Bad link] — one that would work with the current Bad Behavior library — on the
[Bad link] site and install it in my modules directory. I then had to install the
[Bad link] 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 offers the equivalent of "answer files" 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 file" 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 file to them. Use the
-showChoicesXML to find the choices and
-showChoicesAfterApplyingChangesXML to see the outcome of choice changes, respectively.
For what it's worth, the
-query flags 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
[Bad link] transcripts, if you're into that sort of thing. Imagine creating an installer choice change file 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 files for bulk installation or just automation of your build process, it sounds as if this new capability should be really helpful.
[Bad link] — 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
[Bad link] that ships with Mac OS X 10.5 Leopard, and I was dismayed to find it's 1.4. Xar is new to Leopard, but it's got a
$ xar --version
The latest version, 1.5.1, is from June 10. Version 1.5 is from May 14. The benefit of the newer versions is that they have
[Bad link]. Leopard's bundled version is apparently too old to incorporate the fixes 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 filesystem.
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
[Bad link] to document this feature further, from a developer perspective.