fix: restrict entitlements used for helper.app

[deepak1556]

For #312720

[Copilot]

Pull request overview

Restricts the entitlements applied during macOS codesigning for the Electron Helper.app bundle, aiming to avoid the macOS 26 Tahoe network-process crash loop reported in #312720.

Changes:

• Route * Helper.app signing to a dedicated entitlements plist instead of falling back to the main app entitlements.
• Add build/azure-pipelines/darwin/helper-entitlements.plist with a minimal entitlement set (com.apple.security.cs.allow-jit).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
build/darwin/sign.ts	Adds a helper-app-specific entitlements selection branch for Helper.app paths.
build/azure-pipelines/darwin/helper-entitlements.plist	Introduces a minimal entitlements plist intended for the Helper.app bundle.

[deepak1556]

Build to publish on failure for testing https://monacotools.visualstudio.com/Monaco/_build/results?buildId=434082&view=results
Build with profile installed locally https://monacotools.visualstudio.com/Monaco/_build/results?buildId=434088&view=results

[deepak1556]

Although the fix here is the correct path, I wanted to understand why we couldn't catch the crash during manual testing on our devices and only users started reporting after the release. As a first step I created a VM that was not corp managed and there the crash was reliable, this gives some definitive proof to MDM based management was relaxing checks on our corp devices

Running https://gist.github.com/deepak1556/bbfcd0b5e56a05ff5a2afd9ea4285441 on both VM and corp machine yielded similar result, which means user space static validation matches so something at the kernel level was different for the runtime checks to fail.

Next decided to check amfi related settings and the only one that stood out was supplemental_key_reloads

sysctl security.mac.amfi | sort

Sysctl	Corp Machine	VM
security.mac.amfi.supplemental_key_reloads	1	0

The AMFI kernel extension is closed source however we can run DTrace on certain probes to see how the code signature path works between these devices, the probes I setup were

sudo dtrace -n '
fbt:com.apple.driver.AppleMobileFileIntegrity:_ZL22_vnode_check_signatureP5vnodeP5labeliP7cs_blobPjS5_ijPPcPm:entry {
    printf(">>> _vnode_check_signature");
}
fbt:com.apple.driver.AppleMobileFileIntegrity:_ZL22_vnode_check_signatureP5vnodeP5labeliP7cs_blobPjS5_ijPPcPm:return {
    printf("<<< _vnode_check_signature ret=%d", arg1);
}
fbt:com.apple.driver.AppleMobileFileIntegrity:_ZL18_validateCoreTrustP7cs_blobPKhPKcPbPyS5_R21ProfileValidationData:entry {
    printf("  _validateCoreTrust");
}
fbt:com.apple.driver.AppleMobileFileIntegrity:_ZL18_validateCoreTrustP7cs_blobPKhPKcPbPyS5_R21ProfileValidationData:return {
    printf("  _validateCoreTrust ret=%d", arg1);
}
fbt:com.apple.driver.AppleMobileFileIntegrity:_Z29setAndCheckValidationCategoryP7cs_blobjPKc:entry {
    printf("  setAndCheckValidationCategory cat=%d", arg1);
}
fbt:com.apple.driver.AppleMobileFileIntegrity:_Z29setAndCheckValidationCategoryP7cs_blobjPKc:return {
    printf("  setAndCheckValidationCategory ret=%d", arg1);
}
fbt:com.apple.driver.AppleMobileFileIntegrity:_Z29transmuteEntitlementsInDaemonP7cs_blobPPKhPm:entry {
    printf("  transmuteEntitlementsInDaemon");
}
fbt:com.apple.driver.AppleMobileFileIntegrity:_Z29transmuteEntitlementsInDaemonP7cs_blobPPKhPm:return {
    printf("  transmuteEntitlementsInDaemon ret=%d", arg1);
}
fbt:com.apple.driver.AppleMobileFileIntegrity:amfi_is_cdhash_in_trust_cache:entry {
    printf("  amfi_is_cdhash_in_trust_cache");
}
fbt:com.apple.driver.AppleMobileFileIntegrity:amfi_is_cdhash_in_trust_cache:return {
    printf("  amfi_is_cdhash_in_trust_cache ret=%d", arg1);
}
fbt:com.apple.driver.AppleMobileFileIntegrity:_ZL14postValidationP8LazyPathP7cs_blobjP12OSDictionaryhbjPKcPPcPm:entry {
    printf("  postValidation");
}
fbt:com.apple.driver.AppleMobileFileIntegrity:_ZL14postValidationP8LazyPathP7cs_blobjP12OSDictionaryhbjPKcPPcPm:return {
    printf("  postValidation ret=%d", arg1);
}
'

This resulted in the following paths when launching a fresh instance of the app whose CDHash was not cached in the Tickets database.

VM:

_validateCoreTrust ret=1          ← CoreTrust fails ← No trust cache fallback → stops here
_vnode_check_signature ret=1      ← FAILURE → SIGKILL

Corp machine:

_validateCoreTrust ret=1          ← CoreTrust fails (same as VM)
amfi_is_cdhash_in_trust_cache ret=1  ← CDHash found in loadable trust cache!
setAndCheckValidationCategory cat=6  ← CS_VALIDATION_CATEGORY_DEVELOPER_ID
postValidation ret=1              ← accepted
_vnode_check_signature ret=0      ← SUCCESS

After CoreTrust fails, corp machine finds the CDHash in a loadable trust cache and proceeds. VM has no trust cache entry ends up in immediate failure. Now we are getting close,

sudo log show --last boot --predicate 'composedMessage CONTAINS[cd] "trust cache" OR composedMessage CONTAINS[cd] "trustcache" OR composedMessage CONTAINS[cd] "loadTrustCache"' --info --debug | head -30

Corp machine loads trust caches at boot:

kernel: attempting to load 2 external trust cache modules
kernel: loaded external trust cache module: 0
kernel: loaded external trust cache module: 1
kernel: successfully loaded trust cache of type: 13
kernel: successfully loaded trust cache of type: 14
kernel: successfully loaded trust cache of type: 10

MDM enrollment (Intune in our case) causes syspolicyd to proactively assess and cache notarization trust for Developer ID binaries. This populates the kernel's loadable trust cache (types 10/13/14) at boot. When AMFI validates the helper at execve time, it finds the CDHash in the trust cache and accepts the restricted entitlements despite CoreTrust returning failure.

[github-actions]

blocks-ci screenshots changed

Replace the contents of test/componentFixtures/blocks-ci-screenshots.md with:

Updated blocks-ci-screenshots.md

<!-- auto-generated by CI — do not edit manually -->

#### editor/codeEditor/CodeEditor/Dark
![screenshot](https://hediet-screenshots.azurewebsites.net/images/cb32a3e854b5734fe5aaca2318f2e0a42ee821b05ea97883ea42c5ba95edb3c3)

#### editor/codeEditor/CodeEditor/Light
![screenshot](https://hediet-screenshots.azurewebsites.net/images/42624fbba5e0db7f32c224b5eb9c5dd3b08245697ae2e7d2a88be0d7c287129b)

#### editor/inlineChatZoneWidget/InlineChatZoneWidget/Dark
![screenshot](https://hediet-screenshots.azurewebsites.net/images/4baed4b05eeb8aadc8bc2dc633abfc87054cdeea4c35b7a655766063bcfedfed)

#### editor/inlineChatZoneWidget/InlineChatZoneWidget/Light
![screenshot](https://hediet-screenshots.azurewebsites.net/images/b9d098d8ccc2bdb6b816537f14b1f1f3c10dadf294fc0b28d03d6e5a34eaf4c8)

#### editor/inlineChatZoneWidget/InlineChatZoneWidgetTerminated/Dark
![screenshot](https://hediet-screenshots.azurewebsites.net/images/4baed4b05eeb8aadc8bc2dc633abfc87054cdeea4c35b7a655766063bcfedfed)

#### editor/inlineChatZoneWidget/InlineChatZoneWidgetTerminated/Light
![screenshot](https://hediet-screenshots.azurewebsites.net/images/b9d098d8ccc2bdb6b816537f14b1f1f3c10dadf294fc0b28d03d6e5a34eaf4c8)

[vs-code-engineering]

📬 CODENOTIFY

The following users are being notified based on files changed in this PR:

@lszomoru

Matched files:

• build/azure-pipelines/darwin/helper-entitlements.plist