Chrome has started crashing almost immediately after startup. I've reported the issue to the Chrome team here: https://issues.chromium.org/issues/385433270
I'm hoping to debug the issue a bit more myself. This page from the Chrome team https://chromium.googlesource.com/chromium/src/+/master/docs/mac/debugging.md#chrome-builds suggests using the follow to strip off the protections:
codesign --force --sign - path/to/Google\ Chrome.app
However, applying that seems to have no effect:
% codesign --force --sign - /Applications/Google\ Chrome\ copy.app
/Applications/Google Chrome copy.app: replacing existing signature
/Applications/Google Chrome copy.app: resource fork, Finder information, or similar detritus not allowed
% lldb /Applications/Google\ Chrome\ copy.app
(lldb) target create "/Applications/Google Chrome copy.app"
Current executable set to '/Applications/Google Chrome copy.app' (arm64).
(lldb) run
error: process exited with status -1 (attach failed (Not allowed to attach to process. Look in the console messages (Console.app), near the debugserver entries, when the attach failed. The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.))
I have tried other variations like the following based on Stack Overflow, this forum, etc., but with the same result. (I'm still a little vague on the meaning for some flags, sorry.) Though codesign says that it's "replacing existing signature", as far as I can tell, nothing is changing:
% cat <<EOF > debuggee-entitlement.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.get-task-allow</key>
<true/>
</dict>
</plist>
EOF
% codesign --verbose=4 -fs - --options library-validation --entitlements debuggee-entitlement.xml /Applications/Google\ Chrome\ copy.app
/Applications/Google Chrome copy.app: replacing existing signature
/Applications/Google Chrome copy.app: resource fork, Finder information, or similar detritus not allowed
file with invalid attached data: Disallowed xattr com.apple.FinderInfo found on /Applications/Google Chrome copy.app
lldb still fails the same way.
Here's what I see after the above:
% codesign -d -vvv /Applications/Google\ Chrome\ copy.app
Executable=/Applications/Google Chrome copy.app/Contents/MacOS/Google Chrome
Identifier=com.google.Chrome
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=1821 flags=0x12a00(kill,restrict,library-validation,runtime) hashes=46+7 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=5d7beab2b03d9892426076b24acc19815d7a3ff8
CandidateCDHashFull sha256=5d7beab2b03d9892426076b24acc19815d7a3ff8c1446966e422c3c10672626b
Hash choices=sha256
CMSDigest=5d7beab2b03d9892426076b24acc19815d7a3ff8c1446966e422c3c10672626b
CMSDigestType=2
CDHash=5d7beab2b03d9892426076b24acc19815d7a3ff8
Signature size=8989
Authority=Developer ID Application: Google LLC (EQHXZ8M8AV)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Dec 17, 2024 at 2:47:58 PM
Notarization Ticket=stapled
Info.plist entries=44
TeamIdentifier=EQHXZ8M8AV
Runtime Version=15.0.0
Sealed Resources version=2 rules=13 files=63
Internal requirements count=1 size=288
From what I can tell, my codesign runs have changed nothing... I see no diff as compared with what I see running codesign -d on a fresh copy.
Is it possible to strip off the protections on my local instance to allow debugging with lldb? If so, could someone share a command for accomplishing that?
Although I'm asking about this because of Chrome specifically, I'm hoping to learn more about codesigning in general and to be more empowered as a user to be able to debug when an app I depend on is crashing.
Thanks much! Happy Holidays!
