Revert "Notarize serve-sim camera dylibs in macOS releases"#7165
Conversation
This reverts commit ee8bdf1.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThis change removes the macOS serve-sim camera dylib notarization subsystem from the Electron Builder configuration, including its host abstraction, submission/verification loop, credential handling, and test-only exports. It replaces the prior Changes
Sequence Diagram(s)sequenceDiagram
participant ElectronBuilder
participant afterPackHook
participant NodeModules
participant OrcaComputerUseApp
ElectronBuilder->>afterPackHook: invoke after packaging
afterPackHook->>NodeModules: prune and validate runtime dependencies
afterPackHook->>afterPackHook: chmod CLI and serve-sim helper binaries
afterPackHook->>OrcaComputerUseApp: signMacComputerUseHelper (macOS only)
Estimated code review effort: 3/5 (High complexity in the config file due to logic replacement, medium in tests) Related PRs: None identified Suggested labels: build, electron, macos Suggested reviewers: None identified 🐰 A notarizer's script fades away, 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Reverts PR #7077 ("Notarize serve-sim camera dylibs in macOS releases").
Post-release validation against the shipped
v1.4.120-rc.2artifact proved theafterSignhook cannot fix the reported Gatekeeper rejection (#6877), while adding real cost and fragility to every macOS release build.Why the hook cannot work
libSimCameraInjector.dylibis built for the iOS Simulator platform (LC_BUILD_VERSION platform 7, SDK iOS 18.5) — it has to be, since it loads inside simulator processes. Apple's notary service accepts submissions containing simulator binaries (so the hook reported success and the build passed) but never issues Gatekeeper tickets for iOS-simulator arm64 slices.notarytoolreturningAccepteddoes not mean every slice was ticketed.Evidence from the
v1.4.120-rc.2release build (which ran the hook, submissions accepted):spctl -a -t execute→rejected, source=Unnotarized Developer ID— the exact symptom from the issue, on the reporter's architecture (arm64).NOT_FOUND23+ minutes after acceptance; x86_64 slice ticketed.serve-sim-camera-helper(platform 1 = macOS, same directory) gets both slices ticketed automatically by the ordinary outer-app notarization — confirming the pipeline is fine and the dylib's platform is the differentiator.Why revert rather than keep
notarytool --waitround-trips per macOS release (~75s when Apple is fast, up to a 45-minute hang each on a stuck submission) and hard-fails the release on any notary error — release-blocking risk for zero arm64 benefit.What this does not change
notarize: isMacReleaseremains). Shipped artifacts were never functionally affected by the hook — it was build-time only.#6877will be reopened; the follow-up investigation is whether the per-filespctlrejection actually causes the reportedsyspolicyd"Malware rejection" at launch (embedded simulator binaries are normal — Xcode ships many). If it does, the fix direction is keeping the dylib out of Gatekeeper's assessment path, not notarization.Validation
git revertof the squash commitee8bdf1applied cleanly; no commits since the merge touch these files.pnpm exec vitest run --config config/vitest.config.ts config/scripts/electron-builder-config.test.mjs— 19 passed (pre-Notarize serve-sim camera dylibs in macOS releases #7077 baseline).pnpm exec oxfmt --checkandpnpm exec oxlinton both files — clean.grepconfirms noafterSign/notarizeMacServeSimreferences remain; outernotarize: isMacReleaseintact.Made with Orca 🐋