macOS code signing changes, or: check this if your product supports PWAs (was: Mac PWA failures)

[Mark Mentovai]

+embedder-dev, as the question that prompted this message reveals that communication to embedders is warranted.

+bridiver/bsclifton, the author/merger of the referenced Brave commits.

Since 2022-02-15, the way Chromium on macOS validates PWA app_mode_loader shims has changed. This is effective since 98.0.4758.109, 99.0.4844.38, and 100.0.4892.0.

If your product supports PWAs, please check to make sure that they still function correctly after these versions, and if necessary, make any required changes to your code signing process. The framework’s designated requirement is now significant to how app_mode_loader is validated.

Hi, Yngve. We did change the way that we validate the PWA app_mode_loader shim a couple of weeks ago. We did this in response to bug 1281111 and, more generally, bug 1297588. We didn’t intend to break anyone downstream—in fact, we had a discussion about how this would work for downstream consumers, and structured it in a way that we thought would work for everything based on Chromium. And it would have worked, too, if everyone had been signing their packages as we expected, but I now see that this wasn’t the best assumption.

Previously, the requirement imposed on app_mode_loader was identifier "app_mode_loader" and certificate leaf = H"…", with the certificate hash taken from the certificate used to sign the main executable. We realized that this was exposed to version shear, in that any product that changes its code signing certificate would suddenly find that none of the existing app_mode_loader shims would be considered valid or be permitted to connect. This would have affected embedders whenever the certificates they sign their own executables with change in the future.

We seized the opportunity to write a better requirement that would accept app_mode_loader shims signed with both the old and new certificate. Our intent was to set a requirement equivalent to what app_mode_loader’s own designated requirement would normally be, but to build it by referencing what we had available in the browser process. Bug 1297588 meant that the browser executable was no longer a reliable source for signature information (at least in Chrome’s case), but the framework was still viable, so we chose that. And that’s how we arrived at the new app_mode_loader requirement: it’s the framework’s requirement, replacing the framework’s identifier with "app_mode_loader".

This breaks down if the framework’s requirement isn’t structured as expected, or if the way app_mode_loader is signed doesn’t satisfy the constructed requirement for some reason. That shouldn’t have been the case for downstream consumers borrowing our in-tree signing infrastructure (and possibly driver), and we didn’t think it would have been a problem for naïve uses of codesign --sign=… --deep either, but we don’t actually know how downstream consumers are signing products that embed Chromium code, and that’s where a heads-up would have been valuable. Here is that message, tardy as it may be.

Because you asked about Xcode versions: our tools come from Xcode 13.2.1 13C100, the current released version. I don’t see our doc mentioning 13.4 at all, which doesn’t exist yet, not even in beta form. The underlying change in lipo that’s part of the recipe for bug 1297588 and its dependents appeared two years ago in Xcode 11.4, but I note that it’s possible to experience these bugs even if lipo had never changed at all, which is how we’ve arrived at bug 1300598, an 83:1 commentary:code ratio, and a variable named ”gross”.

Mark

Yngve N. Pettersen wrote:

Hi again,
I may have determined a couple of more details.

One is that we are currently using XCode 13.2, not 13.4, which your Google
Doc seems to indicate introduced the problem you are working on.

Additionally, it seems Brave added some extra signing data to fix the
issue.
https://github.com/brave/brave-core/pull/12418/files/63cd41ca5be87dff276bbe9d24a4348fcdd72483
. At least one part of that fix is also referenced in the unit tests for
the shims.

I am now running a test build with our variant of that fix.

On Friday, 4 March, 2022 10:59:37 (+01:00), Yngve N. Pettersen wrote:

 > Hi,
 > I am one of the developers of Vivaldi.
 >
 > We have just started receiving reports about PWAs not working in
Vivaldi's most recent Stable release, based on Chromium 98 (98.0.4758.119)
 >
 > Apparently, users of Brave are also having the same issue
https://community.brave.com/t/updating-to-1-35-104-breaks-all-pwas/346680/20

 >
 >
 > AFAICT this is caused by the commit you introduced in the Mac-only
release of 98 build 109, last week.
 >
 >
https://chromium.googlesource.com/chromium/src/+/e660f5610cf324520b9db9ce86259424df1f15fb%5E%21/

>
 >
 > This is related to your existing bug https://crbug.com/1297588
 >
 > Are there any fixes/workarounds for this issue, short of reverting the
above commit?
 >
--
Sincerely,
Yngve N. Pettersen
Vivaldi Technologies AS

[Mark Mentovai]

Thanks, Brian. I can see where the error appeared now. I filed bug 1303028 to track improving the designated requirement defaults for Chromium.

Brian wrote:

We are using the in-tree signing infrastructure, but it doesn't include the model config for release signing which now appears to require `codesign_requirements_basic` and oddly also `codesign_requirements_outer_app` because for some reason the identifier is dropped from only the outer app when `codesign_requirements_basic` is specified. 

The app mode launcher changes required something after the second quote (the close quote for the identifier) and nothing is there by default unless you add it to `codesign_requirements_basic`. These are the changes we had to make to our signing config to get it working again:

@property

     def codesign_requirements_outer_app(self):

         return 'designated => identifier "' + self.base_bundle_id + '"'

@property

     def codesign_requirements_basic(self):

        return 'and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists / ...'

Tip: missing a couple of *s here?

(Here’s a guide to the OIDs to see what you’re missing out on.)