On macOS, browser.app's nested tool bundles live under Contents/Plug-ins/*.app and Contents/System/*.app. Apple's standard convention for a bundle's plugin folder is PlugIns (no hyphen); codesign --deep walks recognized nested-code locations (Frameworks, the standard PlugIns, etc.) but does not recurse into arbitrarily-named folders like Plug-ins or System.
After macdeployqt rewrites install names/rpaths in these nested executables (install_name_tool), their original ad-hoc/linker-embedded signatures no longer match the on-disk bytes. A subsequent codesign --force --deep -s - browser.app (as run by vlab-macdeployqt.sh) re-signs the outer bundle, Contents/Frameworks, and the Qt PlugIns folder correctly, but silently leaves every tool under Contents/Plug-ins/Contents/System with its now-invalid signature.
Symptom: launching any nested tool (lpfg, cpfg, object, etc.) directly gets killed by the kernel:
kernel: CODE SIGNING: cs_invalid_page(...): p=NNNNN[Lpfg] final status 0x23000200, denying page sending SIGKILL
kernel: CODE SIGNING: process NNNNN[Lpfg]: rejecting invalid page ... in file ".../Contents/Plug-ins/lpfg.app/Contents/MacOS/lpfg" (... tainted:1 ...)
amfid: .../lpfg not valid: "The file is adhoc signed or signed by an unknown certificate chain"
We only noticed because this specific rebuild also happened to be the first ad-hoc-signed binary of its kind ever run directly via Terminal on this machine — which briefly looked like a Developer Mode / Gatekeeper issue (amfid logs a plausible-looking but ultimately unrelated "unknown certificate chain" message) before the kernel's tainted:1 log line pointed at the real cause: a stale signature, not a missing trust grant.
Workaround used locally:
for app in Contents/Plug-ins/*.app Contents/System/*.app; do
codesign --force -s - "$app"
done
codesign --force --deep -s - browser.app # re-sign the outer bundle/Frameworks/PlugIns last
Suggested fix: have vlab-macdeployqt.sh explicitly loop over and re-sign everything in Contents/Plug-ins and Contents/System (in addition to the outer -codesign=- macdeployqt call), after all install_name_tool rewriting is done. Long-term, renaming Plug-ins/System to Apple's conventional PlugIns/similarly-recognized location would let codesign --deep handle this automatically, but that's a bigger structural change.
On macOS,
browser.app's nested tool bundles live underContents/Plug-ins/*.appandContents/System/*.app. Apple's standard convention for a bundle's plugin folder isPlugIns(no hyphen);codesign --deepwalks recognized nested-code locations (Frameworks, the standardPlugIns, etc.) but does not recurse into arbitrarily-named folders likePlug-insorSystem.After
macdeployqtrewrites install names/rpaths in these nested executables (install_name_tool), their original ad-hoc/linker-embedded signatures no longer match the on-disk bytes. A subsequentcodesign --force --deep -s - browser.app(as run byvlab-macdeployqt.sh) re-signs the outer bundle,Contents/Frameworks, and the QtPlugInsfolder correctly, but silently leaves every tool underContents/Plug-ins/Contents/Systemwith its now-invalid signature.Symptom: launching any nested tool (lpfg, cpfg, object, etc.) directly gets killed by the kernel:
We only noticed because this specific rebuild also happened to be the first ad-hoc-signed binary of its kind ever run directly via Terminal on this machine — which briefly looked like a Developer Mode / Gatekeeper issue (
amfidlogs a plausible-looking but ultimately unrelated "unknown certificate chain" message) before the kernel'stainted:1log line pointed at the real cause: a stale signature, not a missing trust grant.Workaround used locally:
Suggested fix: have
vlab-macdeployqt.shexplicitly loop over and re-sign everything inContents/Plug-insandContents/System(in addition to the outer-codesign=-macdeployqt call), after allinstall_name_toolrewriting is done. Long-term, renamingPlug-ins/Systemto Apple's conventionalPlugIns/similarly-recognized location would letcodesign --deephandle this automatically, but that's a bigger structural change.