Closed karanbirsingh closed 2 years ago
This issue has been marked as ready for team triage; we will triage it in our weekly review and update the issue. Thank you for contributing to Accessibility Insights!
Per conversation with Peter, let's do this.
Added the ESRP notarization task to our signed build. Resulted in an error with no details. Unassigning myself to start on feature work.
Picking this up where John left off. Next few items I'm going to try, based on Apple's notarization docs:
hardenedRuntime=true
is the default configuration, but I want to double check because we've seen misleading behavior from electron-builder config before)electron-osx-sign
, which has a default entitlements file, but since we're doing our own signing maybe we aren't getting that benefit?Followed the VS Code team's example; the key realization is that electron-builder uses the codesigning process (specifically, the electron-osx-sign
package) as the means to add the "hardened runtime"/entitlements configuration, but we actually skip this step intentionally since we want ESRP to handle the codesigning. Thankfully, we can ask ESRP to handle the same hardened runtime configuration by passing a parameter for it to the initial codesigning step (not the notarize step). There were a few other minor changes I made during testing that I kept, but I think that was the key one.
The VS Code folks, naturally, have a much more complex mac build process than us; they actually manually invoke electron-osx-sign
themselves using a developer cert in the build agent's keychain (presumably to get tight control over the specific entitlements/hardening configuration), and then send the already-developer-signed file to ESRP to get codesigned again with release certs, and then send it to ESRP again to get the signed packages notarized. For now I've omitted the manual electron-osx-sign
step, but it might be something to explore if this version doesn't work out.
Results: Build #Signing-478 with first examples of notarize step succeeding.
@waabid is testing the resulting artifacts now as I write this, fingers crossed :)
Wahaj found that the app crashes on startup. The relevant snippet of error is:
Process: Accessibility Insights for Android - Insider [98982]
Path: /Applications/Accessibility Insights for Android - Insider.app/Contents/MacOS/Accessibility Insights for Android - Insider
Identifier: com.microsoft.accessibilityinsights.unified.insider
Version: 2020.803.9 (2020.803.9.2020.803.9)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Accessibility Insights for Android - Insider [98982]
User ID: 501
Date/Time: 2020-08-03 15:10:51.195 -0700
OS Version: Mac OS X 10.15.5 (19F101)
Report Version: 12
Bridge OS Version: 4.5 (17P5300)
Anonymous UUID: D58B1136-DAB4-4384-860F-9D25A6897970
Sleep/Wake UUID: 7C8CC498-A472-4469-8CC4-EF94FA722520
Time Awake Since Boot: 59000 seconds
Time Since Wake: 4900 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (Code Signature Invalid)
Exception Codes: 0x0000000000000032, 0x0000316972d02040
Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: Namespace CODESIGNING, Code 0x2
Related issues:
Karan suggested a second example to look at (Bot Framework):
They're using the same basic strategy as VS Code (performing a pre-ESRP-signing step that uses the codesign
tool on the dev box to assign an enlistments file and a hardening config, then sending that to ESRP. Like VS Code, they're signing a .app file (not a .dmg like we're doing), so I can only hope it's a similar process.
Talked to the ESRP team today and confirmed with them that following the examples/guidance from the VS Code and BotFramework-Emulator repos is correct. At a high level, the process is:
.keychain
file on the build agentcodesign
(either directly like BotEmulator-Framework, via electron-osx-sign
like VS Code, or via electron-builder
(which uses electron-osx-sign
) to apply the "hardened runtime" option and the entitlements .plist
s (for our main .app and all its helpers). This must happen after electron-builder
produces the release directory structure but before the structure is packed into .dmg
/.zip
files
.app
s with our derived Developer ID cert; the signature doesn't matter so much, this is mostly a side effect of how you set the entitlements.zip
/.dmg
as we do nowWe've now worked with the ESRP folks and provisioned an Apple developer account that can generate the derived cert we'll need. I've also hooked up placeholder secrets in our usual keyvault and piped them into the signing build. The next steps all require an actual mac for testing/validation:
I've asked Peter to have a mac provisioned for me; moving this feature back to ready for work until I receive it or someone else with a Mac can pick it up, rolling onto web compliance feature in meantime.
@ferBonnin to schedule a small feature for this
This issue requires additional investigation by the Accessibility Insights team. When the issue is ready to be triaged again, we will update the issue with the investigation result and add "status: ready for triage". Thank you for contributing to Accessibility Insights!
Note: further work on this still requires a Mac; it can be done without but it'd be really tedious (using build agents for debugging).
Did some work on this and here is where we currently stand:
Branch: https://github.com/waabid/accessibility-insights-web/tree/macNotarization
What's completed:
What's not working:
What to do next:
codesign -v -vvv --deep <path to app>
locally from downloaded unsigned build bits (any channel is okay) points out issues with files not being correctly signed. We must work through these issues I believe before we can pass the notarization step (it seems). How we resolve these issues is unclear (the above link should provide some guidance on that front as well). It could be folder structure or we could manually sign each file (via another script) instead of using the "--deep" flag and finally I believe entitlements can also play a role.1 It's unclear what entitlements we specifically need for our application; further investigation may be required. The ones being used are a result of looking at what the BotFramework/VSCode teams are doing. This could be a potential reason for issues with signing as adding certain entitlements has reduced errors found using the verify command. More information about the entitlements that concern us can be found here: https://developer.apple.com/documentation/security/hardened_runtime
This has been completed
Describe the bug
Starting Feb 3, the startup workflow on MacOS Catalina is different for unnotarized applications:
We need to check how the unified mac client runs on Catalina, and consider notarizing the app (in addition to existing signing) to remove extra end-user work.