Solipsism Gradient

Posted by 0xced:

Rainer Brockerhoff wrote:

If there’s interest, I may clean up and publish the source sometime, though it uses all sort of gronky old APIs (Resource Manager etc.).

Oh yes, there is interest!

Posted by 0xced:

Rainer Brockerhoff wrote:

   [task launch]; 
   [NSApp terminate:nil];

No need to pass the calling program’s process identifier, and it works from Tiger (10.4) on up.

Although unlikely, the task may be faster to execute than [NSApp terminate:] and the relaunch process would thus fail. By listening to the termination of the calling process, you are guaranteed to always relaunch.
Edit: I’m wrong, Rainer just pointed to me that the task can’t terminate since its first line is a read on the input pipe and it will block there.

Mike Ash recently posted about code signing. We’d talked about the subject a few days before and that is a great summary of Mike’s thoughts about it.

Code signing on Mac OS X is still evolving, but with the release of the iPhone SDK, the subject is suddenly being thrust into the limelight. To quote the Wikipedia article:

Code signing is the process of digitally signing executables and scripts to confirm the software author and guarantee that the code has not been altered or corrupted since it was signed by use of a cryptographic hash.

In the past, code signing has been used on several platforms with differing intents and implementations; Microsoft, for instance, has a driver signing program that lets only Microsoft-certified device drivers run without warnings on Vista. In contrast, here’s a statement from an Apple engineer on the apple-cdsa mailing list:

Windows “code signing” is not only completely different in design and implementation, it also has a completely different *intent*. The Windows version tries to determine whether *Microsoft* thinks your program (or driver etc.) should be used. Mac OS X Code Signing is a general medium to let the manufacturer and user negotiate as to whether/how they want to trust each other, with the system providing the infrastructure to make this possible.

From what I’ve learned about the subject so far, the Mac OS X implementation seems indeed to be aimed in this direction – there’s very little documentation available. Even less is, of course, available for the iPhone OS implementation, and details are under NDA. But let me try to explain what I learned so far.

Mac OS X code signing is an implementation of the X.509 standard public key infrastructure. It depends on a cryptographical algorithm which gives reasonable assurance that signatures cannot be forged with currently wide-available technology. Of course that’s a rapidly moving target, and the twiddly mathematical details are beyond the scope of this post (and, in parts, of my poor brain too).

So, you can have signed executables (single binary files) and signed bundles (which can applications, frameworks, plug-ins and so forth). A signed bundle is easily distinguished by the presence of an extra “CodeResources” file inside the bundle’s Contents folder. This file is a XML file containing, among other data, a dictionary that contains a hash code for every file inside a bundle. It also has a list of “optional” files or folders; this allows you to remove things like unwanted localizations from an application without invalidating the signature. Of course, if you later re-add a localization its hash codes must match the one inside the file. Additionally, a signature is added to the bundle’s executable.

If you check Mac OS X’s system folder and applications, you’ll find that, beginning with Leopard, every framework, application and command-line tool is signed. This signature, by various convoluted means, is checkable (currently only by Apple’s codesign command-line tool). It also points back at Apple’s “root certificate“. This certificate is is a component in X.509’s chain of trust tree, which basically tells you which authorities certify that a particular signature is valid; in effect, when you reach the root of such a tree you have to decide whether the root certificate can be trusted. (X.509 also can be used for distributed, or peer-to-peer, trust networks.) Let’s see how you can check this in practice. Open Terminal and try this:

$ codesign -vvvv /Applications/Safari.app
/Applications/Safari.app: valid on disk
/Applications/Safari.app: satisfies its Designated Requirement

(as usual, type the line after the $ prompt and you should see the resulting lines.)

So this means that the Safari application is signed and its signature is intact. Otherwise, you’d get either a “code object is not signed” message, or if the signature has been tampered with, a “code or signature modified” message. Now let’s try a small variation on the command:

$ codesign -dvvvv /Applications/Safari.app
Executable=/Applications/Safari.app/Contents/MacOS/Safari
Identifier=com.apple.Safari
Format=bundle with Mach-O universal (i386 ppc7400)
CodeDirectory v=20001 size=7621 flags=0x0(none) hashes=375+3 location=embedded
Signature size=4064
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Info.plist entries=23
Sealed Resources rules=9 files=283
Internal requirements count=1 size=68

This gives more information. Specifically, we see that there are 3 “certification authorities” included into the signature, and that there is one “internal requirement”. To see this requirement, try:

$ codesign -dr- /Applications/Safari.app
Executable=/Applications/Safari.app/Contents/MacOS/Safari
host => anchor apple and identifier "com.apple.translate"
# designated => identifier "com.apple.Safari" and anchor apple

This is admittedly hard to wrap your neurons around. From what I understood, the “requirements” are actually a little language that establishes what conditions the signed bundle should satisfy. But satisfy to able to… what? Now there’s where everything is (on purpose) still a little vague. “anchor apple” apparently means that the basic requirement is that Apple’s root certificates be present and trusted. Open the Keychain Access utility, click on “certificates”, and you’ll see somewhere in the list a certificate called “Apple Root Certificate Authority”. You can double-click on it to see details.

But what is all this useful for? Your proverbial “Aunt Tillie” will certainly not be interested in typing commands into Terminal, following certificate chains, and reading up on trust audit procedures. Apple’s keychain software tries to make all that as transparent as possible. Simply logging into Mac OS X can open parts of the keychain, and when Aunt Tillie goes to her banking site, the bank’s certificate should be checked against the keychain’s certificates and with the issuing certification authority, and everything should “just work”. For that to be reliable, Safari’s code signature should also be checked – otherwise it could be hacked by some malicious entity to say that the bank’s site checks out OK even when it’s some phishing site masquerading as that bank!

Signatures and certificates are also checked by the parental control preference panel, by Mail when it receives signed e-mail, and so forth. You may be familiar with the dialog asking if a recently-updated application may access the keychain to store or retrieve passwords; for signed applications, this dialog will be issued only once. If a newly-installed update has the same signature as the previous version, which had already been authorized to access the keychain, it’s assumed to also be trusted to do so.

A similar scenario applies to critical code such as the codesign executable itself. Ideally, such code should refuse to run if it’s modified; Apple has some facilities already in place to do so, and even to detect if an executable ihas been modified while it’s already running by some malicious code injection. However, that sort of thing isn’t widely used yet; mostly because it would break certain facilities, like Input Managers, that people currently rely on.

One aspect I haven’t touched upon yet is the so-called “self-signed certificate”. This is a certificate which is its own root certificate, like the top certificates of the various ‘big” authorities. The difference is that these authorities are large companies that undergo serious auditions and verifications. As an example, Quay is currently self-signed; I’m still evaluating how to publish my certificate in a way that easily allows my users to check if new versions have indeed been signed by myself. Let’s run one of the same verifications on Quay:

$ codesign -dvvvv -r- /Applications/Quay.app
Executable=/Applications/Quay.app/Contents/MacOS/Quay
Identifier=net.brockerhoff.Quay
Format=bundle with Mach-O universal (i386 ppc)
CodeDirectory v=20001 size=245 flags=0x300(kill,hard) hashes=6+3 location=embedded
Signature size=1671
Authority=Rainer Brockerhoff
Signed Time=Mar 8, 2008 08/03 22:28:09
Info.plist entries=14
Sealed Resources rules=4 files=18
host => anchor apple and identifier "com.apple.translate"
# designated => identifier "net.brockerhoff.Quay" and anchor leaf = H"4cbb97c74336f7ee6aa566122a5e7688e1c725dc"

See the difference? It shows only my name as authority, and a SHA1 hashcode at the end. I could publish this hashcode on my site and it would be not too difficult for a technically knowledgeable user to verify that his copy of Quay matches that.

What does this really mean? Actually, not too much. It means that two versions of Quay that give identical names and hashcodes, which additionally match the ones published on this site, giving reasonable assurance that the author of both versions and of the site are the same; but nothing at all beyond that. However, there are ways around that – SHA1 hashcodes can be duplicated with some effort, though perhaps not yet for certificates, and this site doesn’t have a secure (https) variant. A malicious person could easily strip away my code signatures, resign everything with a new self-signed certificate using my name, make a phishing site that looks like mine, and so forth, and to a normal user everything would appear to be OK. Would someone do that for a €7 utility program? Very probably not worth the trouble, but you can’t be sure.

Then again, I could invest in a secure site, an official certificate signed by a trusted authority – perhaps even by Apple itself – and all that would just make the code signature itself more reliable; it wouldn’t necessarily correspond to what extent the code itself can be trusted to always “do the right thing”.

As Mike points out, there’s a huge gap between “signed” and “trusted”. Ultimately you have to trust somebody, or you would be too scared to buy a box at a computer store and open it, much less connect that computer to the Internet or let your children touch it. If I buy a certificate from Apple, and use that to sign my code, you have to trust someone in the certificate chain even if my code seems to “just work”… it wouldn’t necessarily mean that Apple has audited and quadruple-checked my source code. Indeed, it doesn’t even touch the question of whether Apple as a company can be trusted!

All that is still largely theoretical; Mac OS X still runs unsigned code with no problem, even though with some small restrictions regarding use of the keychain, the firewall, and internet access as I mentioned above. But Apple engineers say that in the future code signing will become mandatory. In the next post, I’ll try to discuss the implications of that – especially regarding the upcoming iPhone OS 2.0, where it will be mandatory from the outset.

Well, there’s little actual information to add to Gruber‘s and TidBITS usual comprehensive write-up, but maybe I can explain some parts in more detail, or provide an opinion on how this will impact developers in the future.

Regarding SDK details as such, most of it is under NDA, which I signed yesterday; but some details have been published already. It’s common knowledge that it includes Xcode 3.1, which will very soon be available as an independent (and free) download, and of course included on installation DVDs with any Mac as soon as it gets out of beta. It also includes Interface Builder 3.1 but not the special objects to directly build iPhone windows; this will no doubt follow in the next release.

I was looking forward to getting my hands on the iPhone UI – to date, I haven’t seen one in the flesh (same for the iPod Touch). But fortunately the simulator includes Safari, so at least I can check how this site looks; some pages come in too wide, and I’ll tweak them as soon as I find time. Still, the UI for the few included apps looks great and it’s useful to get a feel for all the animations. Speaking of the simulator, it’s not a hardware-level simulator; it seems to run x86 code, no doubt an easy way to make it even harder for hackers to glean information about the actual iPhone OS implementation.

I suppose this would also explain why the current SDK is Intel-only; the PowerPC version might not have made it in time, or may be too slow, or whatever. Still, it’s a bad precedent. Intel Macs seem to be about 50% of the installed base by now, a year before I thought that would happen, but it’s still too soon for people to stop doing Universal applications. For what it’s worth, I had to install everything on the only Intel Mac I have – a Core Solo mini with 512MB RAM – but it seems to run quite well despite the cramped hardware.

This “iPhone OS” name now seems to be the new “OS X” and it’s… clumsy. Not a good way to indicate a new platform that already includes the Touch and before the end of this year (or so I think) will get new members. Indeed, there are hints that both “mobile” and “touch” were at one time or another the platform name du jour, and hopefully this will prove to be just a beta name.

Certainly nobody in the Mac developer community was surprised that the SDK is based on Xcode, Cocoa and Objective-C; doing otherwise would mean a complete rewrite of the current 1.1.x firmware, and Apple hasn’t enough manpower to pull such a thing off. Besides, it’s certainly a good way to get Macs into the hands of new developers. Still, no doubt some people are miffed or surprised that the SDK doesn’t run in Visual Studio, or that there’s no Java or .NET support; I can imagine them complaining to Microsoft about this (hey, Microsoft owns a good chunk of Apple, or so they probably believe).

Next: the business part. That’s where it gets interesting.

Overnight, Apple’s changed the Leopard Developer Tools page to confirm officially that the tool formerly known as Xray is now called Instruments.

Well, while both names are certainly better than the prototype name (which, supposedly, was “PowerTrace”), I’m both relieved and worried by the change. When the name first came to my attention over a year ago, some Apple folks told me privately that I shouldn’t worry about any conflict with my own XRay utility (now being reincarnated as XRay II). Still, I hoped that the similarity might drive some clients my way, and I even linked from my own page to Apple’s, to avoid any confusion.

Now, this last-minute change is a also little worrying, since it’s probably a symptom of a cease-and-desist letter. This came up so suddenly that even the icon on the Apple site still uses an “x-ray machine” theme. I can’t find any larger Mac software company using any variation of “X-ray”, but who understands how lawyer’s minds work? It might even be a non-software company. Hopefully my new second-generation name will be non-conflicting enough to avoid any trouble.

Rumors say Apple may switch the iPhone main processor to Intel’s upcoming Moorestown.

It’s too early to speculate until details come out, but it wouldn’t be a surprise to hear that Apple is considering this. And it would explain the closedness of the iPhone/iPod touch architecture… after all, once Apple allows third-party apps in, and publishes a toolchain/SDK, they’re pretty much locked into the current architecture, and switching to a new one is a major/slow/costly undertaking.

Consider the previous iPods as a counterexample. Apple has switched architectures there – we can’t even say for sure how often – without any users noticing. With only the UI visible on OS X, and no toolchain/SDK or even documentation of the innards, Apple is free to change things radically between software updates. By all accounts, the 1.0.x software is pretty much a work in progress, and 1.1.1 has probably changed a lot.

So, keeping things closed for now means the software hasn’t stabilized, and very probably the hardware hasn’t stabilized either.

Conclusions:

– the current generation of iPhone/iPod touch will remain closed forever, just like the first generations of iPods;

– an SDK is likely to come out only after everything (especially the hardware) has stabilized;

– Apple is unlikely to invest efforts into implementing TrustZone in the current generation, unless Moorestown (or whatever else they might adopt in the future) has a similar security feature – and maybe not even then;

– the fabled OS X tablet will come out when the new hardware is ready; by that time screens will be ready in the proper sizes; Sony showed an 11″ OLED TV recently, remember…

After several months of tinkering and getting used to the new IB, I just published a first beta of the IB3 plugin for RBSplitView 1.1.4.

Some things haven’t been tested (copy&paste), others don’t work fully (undo), but it seems to work mostly. Please post bug reports in the source forum, or e-mail me. To install, close IB3, unzip the plugin in a convenient location (I don’t think there’s a standard one for IB3), and double-click it.

A full Leopard version will be out around the end of this month, along with source code for the plugin.

OK, here’s what I wrote a few days ago, regarding the Mac OS X transition to Intel:
Rainer Brockerhoff wrote:

…Most Cocoa developers that didn’t call Carbon frameworks to any great extent, or that didn’t have to deal with complex binary files, were able to recompile their apps into the Universal (“fat binary”) format in a few hours or days. In contrast, most developers of Carbon apps of any complexity faced months or years of conversion.

I invited comments on Apple’s carbon-dev mailing list, and some people objected to the paragraph quoted above. In particular, Apple engineer Eric Albert wrote:

I’d probably moved more Mac OS X code to Intel than anyone else before the announcement — some of the iApps and a bunch of other apps, plus a ton of work in the OS — and of the code I’d worked on, the Cocoa apps happened to take more work than the Carbon ones. That was really nothing more than coincidence because the Carbon apps I was working on dealt with structured data better than the Cocoa ones, but there’s nothing inherently more complex about the Intel transition for Carbon than there is for Cocoa. Mathematica, which is most assuredly a complex Carbon app, took four hours to get up and running on Intel, faster than any other app I’ve seen.

The primary reason for some Carbon apps taking a long time to move to Intel was that they weren’t using Mach-O or Xcode at the time the transition was announced and both were required for Intel support.

Carbon apps already using Mach-O and Xcode came over to Intel fairly easily.

Well, that’s quite definite; I was wrong there. I was wondering why, though, and here’s what I found: the RDF is to blame…

Here’s what Steve Jobs said at the WWDC 2005 keynote, where I was physically present, and quite near the front too:

So, let’s take a look at this again: Widgets, Scripts and Java just work. Cocoa apps, literally a few days and your Cocoa app’s going to be running with an Intel version. Carbon apps, it’s to be a few weeks, a few more tweaks, although there are exceptions to that although we maybe overstating it here, which we’ll see in a minute. And and in Metrowerks we don’t know, you’ve got to get to Xcode. So the key here is getting to Xcode.

And I distinctly remember the same point being made later in the reserved “state of the union” sessions: click a checkbox in Xcode, “boom” for Cocoa… not that easy with Carbon.

There it is then. I don’t have any Carbon apps myself, and didn’t have to migrate anything from Metrowerks CodeWarrior either, so I thought Carbon was to blame for stuff like the Adobe Photoshop delay. I’ll update my original post below; thanks to everybody who sent in comments.