Support signing nested binaries with no entitlements

[hafta]

Apologies if rcodesign already has a mechanism to do this. The request is to support signing inner resources with an empty set of entitlements while still signing the outer bundle with entitlements. A workaround is to use an empty xml entitlement list as described below.

With Firefox, we sign the outer bundle with one set of entitlements and some inner .app bundles each with their own set of entitlements. For bare executables such Firefox.app/Contents/MacOS/pingsender, we sign it with no entitlements. We accomplish this by first executing codesign commands to sign the inner dylibs, executables, and bundles and then signing the outer bundle which has the desired effect because codesign does not re-sign already signed nested files. As an example, this script can be used to re-sign a Firefox 119 release build.

With rcodesign, I accomplished the same effect by creating an empty entitlements list file and scoping the --entitlements-xml-path repeatedly for any objects that don't need an entitlement list. As in --entitlements-xml-path Contents/MacOS/pingsender:./empty.xml. Full example here.

Using the empty entitlement list file appears to work (per my limited testing) and the bundle was successfully notarized.

Thanks for developing rcodesign.

[indygreg]

I plan #107 to make this kind of complex, nested set of configs easier to express than CLI arguments.

Right now, if you specify --entitlements-xml-path it will be inherited by all children. I agree that's probably not desirable default behavior, especially for bundles.

The whole configuration inheriting and how nested entities are signed bit needs to be rethought out because a) it was implemented before I grasped how complex nested bundle signing was b) Apple has since said they are going to deprecate codesign --deep, which rcodesign implicitly does by default. My best guess is they are doing so because it is really difficult to express signing settings during recursive signs!

To answer your question, in current rcodesign you have 2 options:

1. The empty entitlements file + --entitlements-xml-path hack you devised. Install an empty file at each root/path where you want to stop entitlements inheritance.
2. Sign each file with empty/different entitlements separately. Existing entitlements embedded in Mach-O binaries should be automatically imported and preserved when re-signing (unless overwritten by explicitly provided settings). But there is a moderate chance of quirks/bugs where that doesn't occur. rcodesign -v output should help diagnose. Please file issues if you see something wonky.

I'll think about the best way to proceed. I really want to make the Firefox signing use case turnkey because it is a good stress test for the UI design of rcodesign.

[indygreg]

After thinking about this some more, I decided to change the inheritance behavior of various signing settings. Entitlements and other settings no longer inherit to nested binaries or bundles by default.

[hafta]

Thanks, I'll take a look.

Regarding the configuration file for rcodesign, for reference, I had a similar idea and I've been using this script for my own signing tests. It maps a json configuration file that is an ordered list of signing settings to use for different glob paths within the bundle to codesign commands. Each entry corresponds to one codesign invocation. Here's an example configuration file.

One thing that I find useful is being able to have the configuration file with all the settings while some settings such as the signing identify can be overwritten on the command line.

[indygreg]

I think your ideas around configuration files are essentially what I implemented. See e.g. https://gregoryszorc.com/docs/apple-codesign/stable/apple_codesign_rcodesign_config_files.html#sign-command-settings.

I tried to make it so every rcodesign sign argument could have a default provided via config files. But you could override via environment variables or CLI arguments as necessary.

If you run into limitations or have any other feedback, please open a new issue!