Unsure how to have .app retain both EVS and OSX signing

[gligon101]

I have an app being built with the Castlabs Electron release using electron-forge. I can run the electron-package script and I will get a working myApp.app file at the end. I'm then able to successfully EVS sign myApp.app and I'm able to execute it, and stream the DRM content that my app is handling.

At this point I would like to OSX sign the app, then pack it up in a DMG and have someone be able to use it. However, when I do the OSX signing with my Apple Distribution credentials, myApp.app no longer works for streaming DRM content. If I check the EVS signing status, it still shows as valid. Is this an entitlements issue? Or am I completely missing something?

[gligon101]

More clear steps as to what I'm experiencing:

• Ran electron-package from electron-forge to give me a basic version of my app
• Manually EVS signed with python3 -m castlabs_evs.vmp /app/output/dir
• Ran the app and verified streaming works
• Manually MacOS signed with electron-osx-sign /path/to/app/myApp.app --identity="My Apple Identity (APPID###)" --provisioning-profile="my.provisionprofile"
• Ran the app. Now streaming doesn't work.
• Run EVS signing verification, it claims it's still EVS signed

[khwaaj]

In macOS Catalina or later, you will need to disable library validation when notarizing your application. This is because your app and the Widevine CDM will be signed by different entities (you and Google).

From your description this is likely the problem you are seeing.

[gligon101]

Thanks for the reply @khwaaj. I put the line in my entitlements.plist and went through the process again with no success. I will say, the FAQ specifically points out that entitlement is part of the notarization process, not the code signing. I'm having problems at the code signing part. Although it also doesn't look like entitlements play a role in notarizing, only in signing. Regardless, I will leave that in there just in case. Unfortunately I'm still at a dead end.

[khwaaj]

I still think this is the issue (although the FAQ may be inconsistently using terminology for notarization/entitlements). The entitlement needs to be applied to the helper app (e.g. the equivalent of Electron.app/Contents/Frameworks/Electron\ Helper.app for your application), not the main app itself.

[gligon101]

Interesting! I wasn't aware that the Helper.app was what needed to be signed. I went ahead and did the electron-osx-sign with that entitlement on electron-osx-sign ./appOutDir/appName.app/Contents/Frameworks/appName\ Helper.app --identity="Apple Distribution: Company Name (######)" --entitlements="./src/electron/entitlements.plist"

Now when I launch the app, I get a blank Electron main window. Any other thoughts or what I might be missing? Again, I really appreciate you having taken the time to reply.

[khwaaj]

I'm not very familiar with electron-osx-sign, but it probably works on the main app level (and signs all enclosed binaries), so in this case you might end up with a broken application since it is partially signed.

It might be possible to tell tell it to apply differing entitlements to the enclosed helper apps somehow, or you can execute codesign yourself to do it. To check which entitlements are applied to an app you can use something like:

% codesign -d --entitlements - --xml /Applications/Google\ Chrome.app | xmllint --format -
Executable=/Applications/Google Chrome.app/Contents/MacOS/Google Chrome
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>com.apple.application-identifier</key>
    <string>EQHXZ8M8AV.com.google.Chrome</string>
    <key>com.apple.developer.associated-domains.applinks.read-write</key>
    <true/>
    <key>com.apple.security.device.audio-input</key>
    <true/>
    <key>com.apple.security.device.bluetooth</key>
    <true/>
    <key>com.apple.security.device.camera</key>
    <true/>
    <key>com.apple.security.device.print</key>
    <true/>
    <key>com.apple.security.device.usb</key>
    <true/>
    <key>com.apple.security.personal-information.location</key>
    <true/>
    <key>keychain-access-groups</key>
    <array>
      <string>EQHXZ8M8AV.com.google.Chrome.devicetrust</string>
      <string>EQHXZ8M8AV.com.google.Chrome.webauthn</string>
    </array>
  </dict>
</plist>

[gligon101]

I think we've got it...? I did the entitlement check like you suggested and it showed a default set of entitlements, which I'm not using. So obviously it wasn't applying them. I ran code signing again but gave it a full path to the entitlements file instead of a relative path, and now if I do an entitlement inspection, it shows correctly. I've packaged it up into a DMG and uploaded it, and my tester was able to download and install and run it.

I really appreciate the help!