I would have responded to your e-mail sooner, but I was on vacation.

Apple’s implementation of nested code signature checking is totally broken, and is subject to a number attacks, all of which have been reported to Apple.

The dates are the dates that I reported these problems to Apple.

17922895 2014-08-05 It is possible to tamper with the nested contents of a sealed .app
18351149 2014-09-16 I need a way to specify a requirement for nested code other than its designated requirement
 https://crbug.com/641394  2016-08-26 (I won’t talk about this one yet, we’re still within the disclosure embargo)

The 2014 radars both became broader than the titles indicate. A notable problem raised in these bug reports relates to the identity of nested code originating from other organizations. The Flash plug-in is a concrete example of code that we ship and would treat as “nested” under what this report seeks. We don’t wish to re-sign Flash because that would involve our attestation of code that we didn’t originate as being legitimately ours, which would expose us to security break-downs such as those described by  bug 641394 .

The chief problem in radar 17922895 and follow-ons is that the nested code validation system doesn’t allow for version locking. From our perspective, that renders it totally broken and unsuitable. Essentially, you can take a Chrome that looks and acts like Chrome 54, but replace the guts with those of Chrome 50, complete with all known vulnerabilities in that version.

In our case, there is no “double verification.” Gatekeeper (syspolicyd) only considers the outer .app, and doesn’t care about the signatures on the inner components. The kernel-level stuff and amfid, which would come into play for “kill” and “library validation” semantics, only care about the Mach-O pages and none of the resource stuff, and thus it doesn’t matter for those purposes whether things are bundled as “nested code” or as “resources”. As it happens, we can’t really use any of those things anyway, because they’re also (you guessed it!) weaker than anticipated, unusable for our purposes, or breakable. See  bug 523045  as an umbrella,  bug 498473  (which resulted in a report to Apple that we tracked under  bug 535702 ), and  bug 497190  (whose case was further weakened by  bug 641394 ).

For our purposes, Gatekeeper checks everything only once, and it actually checks that every file other than the main executable (which is validated differently due to Apple’s design) is exactly as it was when we signed the entire .app. These are the strong semantics that are desirable in a signature system, and the semantics that we want, but “nested code” doesn’t work this way.

The “break the outer signature of apps” language in the tech note isn’t directed at us at all, it’s directed at more naïve updater implementations. Our design is immune to these problems. It’s also immune to all of the holes and breaks that are evident in Apple’s recommended “nested code” form, which is why we’ve stuck with it.