Search results for

“codesign”

3,221 results found

Post

Replies

Boosts

Views

Activity

macOS 11.x system reported an error when using endpoint security
This is .entitlements file: com.apple.developer.endpoint-security.client Code signing: codesign --sign -vvv --timestamp --options=runtime --force --entitlements ./UES.entitlements -s Developer ID Application: XXXX Ltd. (XXXXXX) ./UES.app When I run it on macOS 13.x, it works fine. If I run the system on macOS 11.x, it reports a killed error (if codesign remove --entitlements ./UES.entitlements, Then the startup will not report an error, but the endpoint security rights cannot be used) System log: 2025-04-21 13:58:27.039638+0800 0xd5941 Default 0x0 149 0 amfid: /Applications/UES.app/Contents/MacOS/UES signature not valid: -67050 2025-04-21 13:58:27.039762+0800 0xd5bbf Default 0x0 0 0 kernel: mac_vnode_check_signature: /Applications/UES.app/Contents/MacOS/UES: code signature validation failed fatally: When validating /Applications/UES.app/Contents/MacOS/UES: 2025-04-21 13:58:27.039815+0800 0xd5bbf Default 0x0 0 0 kernel: proc 29354: load code signature error 4 for file UES 2025-04-21 13
Topic: Code Signing SubTopic: Entitlements Tags:
3
0
220
Apr ’25
Reply to notarization - not a valid developer certificate
Thank you. I see, so I was using the wrong type of certificate and that's why notarization was failing. Thank you for your help so far. With the correct cert, I have hit another blocker: I sent off the certificate signing request and downloaded the correct certificate and imported it into keychain access. It has the name: Developer ID Application: COMPANY REDACTED (REDACTED ID) Green check mark: This certificate is valid. I see other information like the issuer: Developer ID Certification Authority Apple Certification Authority This matches what you mentioned above. Just making sure. And, I have removed the old certificate from keychain access and disk so it won't interfere. I mention this because of the below blocker. To my knowledge, this does not look like a self signed cert. Which... would be weird as I downloaded it from the certificate signing request. When I go to code sign now: codesign -s REDACTED ID SAME AS DEVELOPER ID APPLICATION CERT -f --timestamp -o runtime -i com.redacted.hello_world
Topic: Code Signing SubTopic: Notarization
Apr ’25
notarization - not a valid developer certificate
I have a binary which I have signed with a valid developer certificate. Here is how I verify the signature was correctly applied: % codesign -dvv ./test_program.exe Executable=/Users/REDACTED/code_signing/test_program.exe Identifier=com.REDACTED.hello_world Format=Mach-O thin (arm64) CodeDirectory v=20500 size=489 flags=0x10000(runtime) hashes=9+2 location=embedded Signature size=9071 Authority=Mac Developer: REDACTED NAME (REDACTED_ID) Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CA Timestamp=Apr 16, 2025 at 11:26:43 AM Info.plist=not bound TeamIdentifier=REDACTED Runtime Version=14.2.0 Sealed Resources=none Internal requirements count=1 size=192 ============================== Additionally, I have confirmed in keychain access that my certificate is valid. Here is the output from the GUI: Issued by: Apple Worldwide Developer Relations Certification Authority Expires: Wednesday, April 15, 2026 at 3:50:14 PM Eastern Daylight Time This certificate is valid =
Topic: Code Signing SubTopic: Notarization
2
0
143
Apr ’25
macOS 11.x system reported an error when using endpoint security
This is my .entitlements file: Code signing: codesign --sign -vvv --timestamp --options=runtime --force --entitlements ./UES.entitlements -s Developer ID Application: XXX. (XXXXXXX) ./UES.app I work fine in the macOS 13.x system, but the killed error occurs in macOS11.x. The system log is displayed as follows: (If codesign remove the --entitlements ./UES.entitlements, it will operate normally) 2025-04-21 13:58:27.039638+0800 0xd5941 Default 0x0 149 0 amfid: /Applications/UES.app/Contents/MacOS/UES signature not valid: -67050 2025-04-21 13:58:27.039762+0800 0xd5bbf Default 0x0 0 0 kernel: mac_vnode_check_signature: /Applications/UES.app/Contents/MacOS/UES: code signature validation failed fatally: When validating /Applications/UES.app/Contents/MacOS/UES: 2025-04-21 13:58:27.039815+0800 0xd5bbf Default 0x0 0 0 kernel: proc 29354: load code signature error 4 for file UES 2025-04-21 13:58:27.040720+0800 0xd5bc0 Default 0x0 0 0 kernel: (AppleSystemPolicy) ASP: Security policy would not allow proc
Topic: Code Signing SubTopic: Entitlements Tags:
1
0
165
Apr ’25
macOS 11.x system reported an error when using endpoint security
This is .entitlements file: com.apple.developer.endpoint-security.client Code signing: codesign --sign -vvv --timestamp --options=runtime --force --entitlements ./UES.entitlements -s Developer ID Application: XXXX Ltd. (XXXXXX) ./UES.app When I run it on macOS 13.x, it works fine. If I run the system on macOS 11.x, it reports a killed error (if codesign remove --entitlements ./UES.entitlements, Then the startup will not report an error, but the endpoint security rights cannot be used) System log: 2025-04-21 13:58:27.039638+0800 0xd5941 Default 0x0 149 0 amfid: /Applications/UES.app/Contents/MacOS/UES signature not valid: -67050 2025-04-21 13:58:27.039762+0800 0xd5bbf Default 0x0 0 0 kernel: mac_vnode_check_signature: /Applications/UES.app/Contents/MacOS/UES: code signature validation failed fatally: When validating /Applications/UES.app/Contents/MacOS/UES: 2025-04-21 13:58:27.039815+0800 0xd5bbf Default 0x0 0 0 kernel: proc 29354: load code signature error 4 for file UES 2025-04-21 13
Topic: Code Signing SubTopic: Entitlements
1
0
98
Apr ’25
add /usr/bin/codesign to acl for private key
Displaying attribute for a private key I see a number of applications that are allowed to access it without needing a password e.g. racoon; Keychain Access.app; Certificate Assitant.app etc.. I want to add /usr/bin/codesign to the list but the gui window that pops up when I click on + doesn't seem to allow me to do that :( How do I do it please
Topic: Code Signing SubTopic: General
3
0
75
Apr ’25
codesign - edited signature
Hey all! I'm building a Python based app with PySide6-deploy. This gives me a .app directory with all the necessary things already in it. To be able to distribute this I provided just the .app path to the codesign looking like this: codesign -s My Name --keychain keychain -f --deep RenderRob.app If I try to check or sign the package, it looks promising: codesign --verify ... RenderRob.app: valid on disk RenderRob.app: satisfies its Designated Requirement Unfortunately this signed package does not work when checking with spctl. spctl --assess --verbose RenderRob.app/Contents/MacOS/libcrypto.3.dylib RenderRob.app/Contents/MacOS/libcrypto.3.dylib: rejected If I look in the log of the notarizing, I saw that something is off with signature of the binary dependencies. Then I checked the binary dependencies, it turns out it complains about an edited signature: codesign -dv -verbose=4 RenderRob.app/Contents/MacOS/libcrypto.3.dylib RenderRob.app/Contents/MacOS/libcrypto.3.dylib: edi
Topic: Code Signing SubTopic: Certificates, Identifiers & Profiles
2
0
144
Apr ’25
codesign add extended attributes to some files
The Codesign command adds extended attributes to files that previously had no extended attributes. In my case codesign add following extended attributes to text file in Frrameworks folder: com.apple.cs.CodeDirectory com.apple.cs.CodeRequirements com.apple.cs.CodeRequirements-1 com.apple.cs.CodeSignature Can I somehow prevent this behavior? Thank you.
Topic: Code Signing SubTopic: General Tags:
2
0
182
Apr ’25
Missing code-signing certificate when uploading MacOS installer to AppStore
Hi there! I have an issue with uploading a PKG installer to the MacOS AppStore. Uploading with: xcrun altool --upload-app -t macos -f $PKGPATH -u $DEVELOPER_ID -p $APP_SPECIFIC_PWD results in error: *** Error: Validation failed Invalid Provisioning Profile. The provisioning profile included in the bundle com.frogblue.frogCom [com.frogblue.frogCom.pkg/Payload/frogSIP.app] is invalid. [Missing code-signing certificate.] For more information, visit the macOS Developer Portal. (ID: fc4e5488-6d09-4ab2-b1f7-017a33c69723) (409) Application seems to be correctly code signed with „3rd Party Mac Developer Application“ certificate. codesign -dv --verbose=4 /Users/dietmar.finkler/Desktop/frogSIP/deploy/frogSIP.app Identifier=com.frogblue.frogCom Format=app bundle with Mach-O universal (x86_64 arm64) CodeDirectory v=20500 size=266432 flags=0x10000(runtime) hashes=8315+7 location=embedded VersionPlatform=1 VersionMin=720896 VersionSDK=918784 Hash type=sha256 size=32 CandidateCDHash sha256=923de799a54616706b76050b5
Topic: Code Signing SubTopic: Certificates, Identifiers & Profiles Tags:
3
0
661
Apr ’25
Reply to Missing code-signing certificate when uploading MacOS installer to AppStore
Dietmar, I had a similar issue some time ago. It sounds like you've navigated a complex signing process, and you're very close! The error message clearly points to an issue with a debug symbol file (.dSYM) within your application bundle having an Apple-reserved bundle identifier (com.apple.xcode.dsym...). This typically happens when these files aren't properly handled during the deployment and signing process for third-party applications. Understanding the Error: The App Store Connect validation is rejecting your build because it found a .dSYM file with a bundle identifier that belongs to Apple. This suggests that either: Debug Symbols for Qt Plugins are Included Incorrectly: The .dSYM file for the libqtqmlcoreplugin.dylib (a Qt plugin) is being bundled in a way that retains Apple's internal identifier. Incorrect Handling of .dSYM Files during macdeployqt6: The macdeployqt6 tool might be copying these debug symbol files without the necessary modifications for App Store distribution. Strategies for Correctly M
Topic: Code Signing SubTopic: Certificates, Identifiers & Profiles Tags:
Apr ’25
Multiple Executables in a Single Bundle Fails to Launch Others After Codesign
We have a rather complex network of dependencies for our application stack and, from it, we create multiple unique executables that are placed into the Contents/MacOS directory of our bundle. MyApp.app `- Contents/ `- Frameworks/... `- MacOS/ `- exec_a `- exec_b `- Resources/... Both executables require the same dependencies (and use the same shared .dylib files built as targets in the same project) so it makes sense for them to be in the same place rather than in their own .app folder as I understand it. Qt Libs -> core_lib.dylib -> gui_lib.dylib -> exec_a `-> exec_b etc. We've confirmed build artifacts are correct and the rpath/dependencies are all clean. When in development, all executables run as expected and we can command exec_a (the executable we're listing in the primary Info.plist) to launch exec_b at any time. Once the bundle is signed, however, we cannot get exec_b to launch in any capacity. Even lldb dies right away because it can't attach to anything. We assume this is something in th
Topic: Code Signing SubTopic: General Tags:
8
0
357
Apr ’25
Reply to codesign add extended attributes to some files
The presence of code signing extended attributes is worrying, and it’s definitely something you should investigate and try to fix. It typically means that your code isn’t following the rules outlined in Placing Content in a Bundle, or you’re manually signing code and not following the process in Creating distribution-signed code for macOS. By way of explanation, code signing uses these extended attributes when it’s signing a data item as if it were code. As the data item doesn’t have a place to store the code signature, codesign places it in extended attributes. See TN3126 Inside Code Signing: Hashes for more on that. These extended attributes are a worry for two reasons. First, it’s not uncommon for code to be transferred via a channel that doesn’t preserve extended attributes. If that happens to code that uses extended attributes for its code signature, it breaks the code signature O-: The other issue is that the most common cause of this problem is a bad bundle structure and, quoting Placing Conte
Topic: Code Signing SubTopic: General Tags:
Apr ’25
Reply to add /usr/bin/codesign to acl for private key
[quote='781889021, perdrix52, /thread/781889, /profile/perdrix52'] I want to add /usr/bin/codesign to the list but the gui window that pops up when I click on + doesn't seem to allow me to do that [/quote] That works for me (testing on macOS 15.4). Within the file sheet, press command-shift-G and enter /usr into the path. You can then navigate to /usr/bin and select codesign. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Topic: Code Signing SubTopic: General
Apr ’25
codesign fails with no explanation
When I first tried to sign my local unit test with the identity generated by Xcode, it failed because the intermediate certificate was missing. In that case, the error message explained that the trust chain could not be completed. But after installing the correct intermediate, codesign still fails, but no longer gives any explanation: codesign -f -s '0EFE7E591A4E690842094B8EC5AFDFE059637D3C' build/Darwin-Xcode-arm64_obf/bin/Release/UNITTEST build/Darwin-Xcode-arm64_obf/bin/Release/UNITTEST: replacing existing signature build/Darwin-Xcode-arm64_obf/bin/Release/UNITTEST: errSecInternalComponent It's the same error line errSecInternalComponent. Is there a log somewhere that might explain what exactly is the error?
Topic: Code Signing SubTopic: General
3
0
99
Apr ’25
Reply to notarization - not a valid developer certificate
You have misunderstood the requirements here. Consider this: % codesign -dvv ./test_program.exe … Authority=Mac Developer: REDACTED NAME (REDACTED_ID) Mac Developer signing identities are for day-to-day development. The notary service requires that your code be signed by a Develeoper ID signing identity. For code that means Developer ID Application: TTT, where TTT identifies your team. If you’re signing code manually, I recommend that you read: Creating distribution-signed code for macOS Packaging Mac software for distribution Finally, Developer ID signing identities are precious, so you should manage them carefully. See The Care and Feeding of Developer ID. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Topic: Code Signing SubTopic: Notarization
Apr ’25
macOS 11.x system reported an error when using endpoint security
This is .entitlements file: com.apple.developer.endpoint-security.client Code signing: codesign --sign -vvv --timestamp --options=runtime --force --entitlements ./UES.entitlements -s Developer ID Application: XXXX Ltd. (XXXXXX) ./UES.app When I run it on macOS 13.x, it works fine. If I run the system on macOS 11.x, it reports a killed error (if codesign remove --entitlements ./UES.entitlements, Then the startup will not report an error, but the endpoint security rights cannot be used) System log: 2025-04-21 13:58:27.039638+0800 0xd5941 Default 0x0 149 0 amfid: /Applications/UES.app/Contents/MacOS/UES signature not valid: -67050 2025-04-21 13:58:27.039762+0800 0xd5bbf Default 0x0 0 0 kernel: mac_vnode_check_signature: /Applications/UES.app/Contents/MacOS/UES: code signature validation failed fatally: When validating /Applications/UES.app/Contents/MacOS/UES: 2025-04-21 13:58:27.039815+0800 0xd5bbf Default 0x0 0 0 kernel: proc 29354: load code signature error 4 for file UES 2025-04-21 13
Topic: Code Signing SubTopic: Entitlements Tags:
Replies
3
Boosts
0
Views
220
Activity
Apr ’25
Reply to notarization - not a valid developer certificate
Thank you. I see, so I was using the wrong type of certificate and that's why notarization was failing. Thank you for your help so far. With the correct cert, I have hit another blocker: I sent off the certificate signing request and downloaded the correct certificate and imported it into keychain access. It has the name: Developer ID Application: COMPANY REDACTED (REDACTED ID) Green check mark: This certificate is valid. I see other information like the issuer: Developer ID Certification Authority Apple Certification Authority This matches what you mentioned above. Just making sure. And, I have removed the old certificate from keychain access and disk so it won't interfere. I mention this because of the below blocker. To my knowledge, this does not look like a self signed cert. Which... would be weird as I downloaded it from the certificate signing request. When I go to code sign now: codesign -s REDACTED ID SAME AS DEVELOPER ID APPLICATION CERT -f --timestamp -o runtime -i com.redacted.hello_world
Topic: Code Signing SubTopic: Notarization
Replies
Boosts
Views
Activity
Apr ’25
notarization - not a valid developer certificate
I have a binary which I have signed with a valid developer certificate. Here is how I verify the signature was correctly applied: % codesign -dvv ./test_program.exe Executable=/Users/REDACTED/code_signing/test_program.exe Identifier=com.REDACTED.hello_world Format=Mach-O thin (arm64) CodeDirectory v=20500 size=489 flags=0x10000(runtime) hashes=9+2 location=embedded Signature size=9071 Authority=Mac Developer: REDACTED NAME (REDACTED_ID) Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CA Timestamp=Apr 16, 2025 at 11:26:43 AM Info.plist=not bound TeamIdentifier=REDACTED Runtime Version=14.2.0 Sealed Resources=none Internal requirements count=1 size=192 ============================== Additionally, I have confirmed in keychain access that my certificate is valid. Here is the output from the GUI: Issued by: Apple Worldwide Developer Relations Certification Authority Expires: Wednesday, April 15, 2026 at 3:50:14 PM Eastern Daylight Time This certificate is valid =
Topic: Code Signing SubTopic: Notarization
Replies
2
Boosts
0
Views
143
Activity
Apr ’25
macOS 11.x system reported an error when using endpoint security
This is my .entitlements file: Code signing: codesign --sign -vvv --timestamp --options=runtime --force --entitlements ./UES.entitlements -s Developer ID Application: XXX. (XXXXXXX) ./UES.app I work fine in the macOS 13.x system, but the killed error occurs in macOS11.x. The system log is displayed as follows: (If codesign remove the --entitlements ./UES.entitlements, it will operate normally) 2025-04-21 13:58:27.039638+0800 0xd5941 Default 0x0 149 0 amfid: /Applications/UES.app/Contents/MacOS/UES signature not valid: -67050 2025-04-21 13:58:27.039762+0800 0xd5bbf Default 0x0 0 0 kernel: mac_vnode_check_signature: /Applications/UES.app/Contents/MacOS/UES: code signature validation failed fatally: When validating /Applications/UES.app/Contents/MacOS/UES: 2025-04-21 13:58:27.039815+0800 0xd5bbf Default 0x0 0 0 kernel: proc 29354: load code signature error 4 for file UES 2025-04-21 13:58:27.040720+0800 0xd5bc0 Default 0x0 0 0 kernel: (AppleSystemPolicy) ASP: Security policy would not allow proc
Topic: Code Signing SubTopic: Entitlements Tags:
Replies
1
Boosts
0
Views
165
Activity
Apr ’25
macOS 11.x system reported an error when using endpoint security
This is .entitlements file: com.apple.developer.endpoint-security.client Code signing: codesign --sign -vvv --timestamp --options=runtime --force --entitlements ./UES.entitlements -s Developer ID Application: XXXX Ltd. (XXXXXX) ./UES.app When I run it on macOS 13.x, it works fine. If I run the system on macOS 11.x, it reports a killed error (if codesign remove --entitlements ./UES.entitlements, Then the startup will not report an error, but the endpoint security rights cannot be used) System log: 2025-04-21 13:58:27.039638+0800 0xd5941 Default 0x0 149 0 amfid: /Applications/UES.app/Contents/MacOS/UES signature not valid: -67050 2025-04-21 13:58:27.039762+0800 0xd5bbf Default 0x0 0 0 kernel: mac_vnode_check_signature: /Applications/UES.app/Contents/MacOS/UES: code signature validation failed fatally: When validating /Applications/UES.app/Contents/MacOS/UES: 2025-04-21 13:58:27.039815+0800 0xd5bbf Default 0x0 0 0 kernel: proc 29354: load code signature error 4 for file UES 2025-04-21 13
Topic: Code Signing SubTopic: Entitlements
Replies
1
Boosts
0
Views
98
Activity
Apr ’25
add /usr/bin/codesign to acl for private key
Displaying attribute for a private key I see a number of applications that are allowed to access it without needing a password e.g. racoon; Keychain Access.app; Certificate Assitant.app etc.. I want to add /usr/bin/codesign to the list but the gui window that pops up when I click on + doesn't seem to allow me to do that :( How do I do it please
Topic: Code Signing SubTopic: General
Replies
3
Boosts
0
Views
75
Activity
Apr ’25
codesign - edited signature
Hey all! I'm building a Python based app with PySide6-deploy. This gives me a .app directory with all the necessary things already in it. To be able to distribute this I provided just the .app path to the codesign looking like this: codesign -s My Name --keychain keychain -f --deep RenderRob.app If I try to check or sign the package, it looks promising: codesign --verify ... RenderRob.app: valid on disk RenderRob.app: satisfies its Designated Requirement Unfortunately this signed package does not work when checking with spctl. spctl --assess --verbose RenderRob.app/Contents/MacOS/libcrypto.3.dylib RenderRob.app/Contents/MacOS/libcrypto.3.dylib: rejected If I look in the log of the notarizing, I saw that something is off with signature of the binary dependencies. Then I checked the binary dependencies, it turns out it complains about an edited signature: codesign -dv -verbose=4 RenderRob.app/Contents/MacOS/libcrypto.3.dylib RenderRob.app/Contents/MacOS/libcrypto.3.dylib: edi
Topic: Code Signing SubTopic: Certificates, Identifiers & Profiles
Replies
2
Boosts
0
Views
144
Activity
Apr ’25
codesign add extended attributes to some files
The Codesign command adds extended attributes to files that previously had no extended attributes. In my case codesign add following extended attributes to text file in Frrameworks folder: com.apple.cs.CodeDirectory com.apple.cs.CodeRequirements com.apple.cs.CodeRequirements-1 com.apple.cs.CodeSignature Can I somehow prevent this behavior? Thank you.
Topic: Code Signing SubTopic: General Tags:
Replies
2
Boosts
0
Views
182
Activity
Apr ’25
Missing code-signing certificate when uploading MacOS installer to AppStore
Hi there! I have an issue with uploading a PKG installer to the MacOS AppStore. Uploading with: xcrun altool --upload-app -t macos -f $PKGPATH -u $DEVELOPER_ID -p $APP_SPECIFIC_PWD results in error: *** Error: Validation failed Invalid Provisioning Profile. The provisioning profile included in the bundle com.frogblue.frogCom [com.frogblue.frogCom.pkg/Payload/frogSIP.app] is invalid. [Missing code-signing certificate.] For more information, visit the macOS Developer Portal. (ID: fc4e5488-6d09-4ab2-b1f7-017a33c69723) (409) Application seems to be correctly code signed with „3rd Party Mac Developer Application“ certificate. codesign -dv --verbose=4 /Users/dietmar.finkler/Desktop/frogSIP/deploy/frogSIP.app Identifier=com.frogblue.frogCom Format=app bundle with Mach-O universal (x86_64 arm64) CodeDirectory v=20500 size=266432 flags=0x10000(runtime) hashes=8315+7 location=embedded VersionPlatform=1 VersionMin=720896 VersionSDK=918784 Hash type=sha256 size=32 CandidateCDHash sha256=923de799a54616706b76050b5
Topic: Code Signing SubTopic: Certificates, Identifiers & Profiles Tags:
Replies
3
Boosts
0
Views
661
Activity
Apr ’25
Reply to Missing code-signing certificate when uploading MacOS installer to AppStore
Dietmar, I had a similar issue some time ago. It sounds like you've navigated a complex signing process, and you're very close! The error message clearly points to an issue with a debug symbol file (.dSYM) within your application bundle having an Apple-reserved bundle identifier (com.apple.xcode.dsym...). This typically happens when these files aren't properly handled during the deployment and signing process for third-party applications. Understanding the Error: The App Store Connect validation is rejecting your build because it found a .dSYM file with a bundle identifier that belongs to Apple. This suggests that either: Debug Symbols for Qt Plugins are Included Incorrectly: The .dSYM file for the libqtqmlcoreplugin.dylib (a Qt plugin) is being bundled in a way that retains Apple's internal identifier. Incorrect Handling of .dSYM Files during macdeployqt6: The macdeployqt6 tool might be copying these debug symbol files without the necessary modifications for App Store distribution. Strategies for Correctly M
Topic: Code Signing SubTopic: Certificates, Identifiers & Profiles Tags:
Replies
Boosts
Views
Activity
Apr ’25
Multiple Executables in a Single Bundle Fails to Launch Others After Codesign
We have a rather complex network of dependencies for our application stack and, from it, we create multiple unique executables that are placed into the Contents/MacOS directory of our bundle. MyApp.app `- Contents/ `- Frameworks/... `- MacOS/ `- exec_a `- exec_b `- Resources/... Both executables require the same dependencies (and use the same shared .dylib files built as targets in the same project) so it makes sense for them to be in the same place rather than in their own .app folder as I understand it. Qt Libs -> core_lib.dylib -> gui_lib.dylib -> exec_a `-> exec_b etc. We've confirmed build artifacts are correct and the rpath/dependencies are all clean. When in development, all executables run as expected and we can command exec_a (the executable we're listing in the primary Info.plist) to launch exec_b at any time. Once the bundle is signed, however, we cannot get exec_b to launch in any capacity. Even lldb dies right away because it can't attach to anything. We assume this is something in th
Topic: Code Signing SubTopic: General Tags:
Replies
8
Boosts
0
Views
357
Activity
Apr ’25
Reply to codesign add extended attributes to some files
The presence of code signing extended attributes is worrying, and it’s definitely something you should investigate and try to fix. It typically means that your code isn’t following the rules outlined in Placing Content in a Bundle, or you’re manually signing code and not following the process in Creating distribution-signed code for macOS. By way of explanation, code signing uses these extended attributes when it’s signing a data item as if it were code. As the data item doesn’t have a place to store the code signature, codesign places it in extended attributes. See TN3126 Inside Code Signing: Hashes for more on that. These extended attributes are a worry for two reasons. First, it’s not uncommon for code to be transferred via a channel that doesn’t preserve extended attributes. If that happens to code that uses extended attributes for its code signature, it breaks the code signature O-: The other issue is that the most common cause of this problem is a bad bundle structure and, quoting Placing Conte
Topic: Code Signing SubTopic: General Tags:
Replies
Boosts
Views
Activity
Apr ’25
Reply to add /usr/bin/codesign to acl for private key
[quote='781889021, perdrix52, /thread/781889, /profile/perdrix52'] I want to add /usr/bin/codesign to the list but the gui window that pops up when I click on + doesn't seem to allow me to do that [/quote] That works for me (testing on macOS 15.4). Within the file sheet, press command-shift-G and enter /usr into the path. You can then navigate to /usr/bin and select codesign. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Topic: Code Signing SubTopic: General
Replies
Boosts
Views
Activity
Apr ’25
codesign fails with no explanation
When I first tried to sign my local unit test with the identity generated by Xcode, it failed because the intermediate certificate was missing. In that case, the error message explained that the trust chain could not be completed. But after installing the correct intermediate, codesign still fails, but no longer gives any explanation: codesign -f -s '0EFE7E591A4E690842094B8EC5AFDFE059637D3C' build/Darwin-Xcode-arm64_obf/bin/Release/UNITTEST build/Darwin-Xcode-arm64_obf/bin/Release/UNITTEST: replacing existing signature build/Darwin-Xcode-arm64_obf/bin/Release/UNITTEST: errSecInternalComponent It's the same error line errSecInternalComponent. Is there a log somewhere that might explain what exactly is the error?
Topic: Code Signing SubTopic: General
Replies
3
Boosts
0
Views
99
Activity
Apr ’25
Reply to notarization - not a valid developer certificate
You have misunderstood the requirements here. Consider this: % codesign -dvv ./test_program.exe … Authority=Mac Developer: REDACTED NAME (REDACTED_ID) Mac Developer signing identities are for day-to-day development. The notary service requires that your code be signed by a Develeoper ID signing identity. For code that means Developer ID Application: TTT, where TTT identifies your team. If you’re signing code manually, I recommend that you read: Creating distribution-signed code for macOS Packaging Mac software for distribution Finally, Developer ID signing identities are precious, so you should manage them carefully. See The Care and Feeding of Developer ID. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Topic: Code Signing SubTopic: Notarization
Replies
Boosts
Views
Activity
Apr ’25