Hello, I am normally a windows programmer, but I am trying to get my PySide/Qt app into the app store. I'm almost there, I just have a couple of questions about the signing process. I have two laptops, one intel silicon, one mac silicon. I created 2 CSR's, one on each laptop and used them to generate 2 Mac Installer Distribution certificates and 2 Mac App Distribution certificates. When it came to downloading the provisioning profile, I selected one Mac App Distrbution Certificate on the interface at aninterestingwebsite.com, saved it and then downloaded to the appropriate laptop. I then switched the provisioning profile to the other Mac App Distribution Certificate and downloaded it to the other laptop. I then built the app and uploaded everything using xcrun altool. On the intel machine only(which has the first provisioning profile) I successfully uploaded the package but I get an email identifying lots of similar errors of the type (Lets call it error1): ITMS-90284: Invalid Code Signing - The executable XXXXX must be signed with the certificate that is contained in the provisioning profile. On the ARM machine only i get the following error (Lets call it error2): ITMS-91109: Invalid package contents - The package contains one or more files with the com.apple.quarantine extended file attribute, such as XXXXXXXX embedded.provisionprofile”. This attribute isn’t permitted in macOS apps distributed on TestFlight or the App Store. Please remove the attribute from all files within your app and upload again. On both I get the following error lets call it error3: ITMS-90886: 'Cannot be used with TestFlight because the signature for the bundle at XXXXX is missing an application identifier but has an application identifier in the provisioning profile for the bundle. Bundles with application identifiers in the provisioning profile are expected to have the same identifier signed into the bundle in order to be eligible for TestFlight.' My first inclination is that all the error1's are coming from having two sets of CSRs, Mac Distribution certificates, provisioning profiles etc. Should I have only used one CSR and made one each of the Certificates? I don't know why I have error2. I don't know where the quarantine attribute is coming from and why it would affect the mac silicon and not the intel. Any ideas? my entitlements file has the following: <key>com.apple.security.cs.allow-jit</key> <true/> <key>com.apple.security.cs.allow-unsigned-executable-memory</key> <true/> <key>com.apple.security.cs.disable-library-validation</key> <true/> <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.device.bluetooth</key> Error3 is the one where I need to try a few things but knowing what is expected will help. In the provisioning profile when viewed at aninterestingwebsite.com it has the APP ID listed as the 10 digit id followed by the bundle ID but I sometimes see just the 10 digit app ID being used and sometimes the bundle ID. I know that it's up to me to figure out how to get it into the build, but knowing what it should be would be helpful. On the other hand the text "Bundles with application identifiers in the provisioning profile ..." indicates that if the application identifier was not in the provisioning profile i might get away with it, but this might be grasping at straws. If you have made it this far, thank you for reading.

I’ve been wrestling with this for nearly a week now and none of the proposed fixes have worked. I’m trying to resign an app via Jenkins and have done the following: Created a custom keychain Imported the required .p12 certificates Installed the Apple WWDR certificate in the System keychain Made the login keychain my default Added my development keychain, the login keychain and the System keychain to the user keychain list Unlocked my development keychain Confirmed my signing identity is present Granted the appropriate partition list access to the keychain "security set-key-partition-list -S apple-tool:,codesign: -k pwd /Users/ec2-user/Library/Keychains/development.keychain-db" Yet when I invoke Fastlane’s resign action, I still see: _floatsignTemp/Payload/EverMerge.app/Frameworks/AppLovinSDK.framework: replacing existing signature _floatsignTemp/Payload/EverMerge.app/Frameworks/AppLovinSDK.framework: errSecInternalComponent Encountered an error, aborting! Any guidance on what might be causing this errSecInternalComponent failure or how to get the resign step to succeed would be highly appreciated.

Is it possible to have some additional content at Versions/A/ in a macOS Framework bundle that is not in any of the standard folders? Will there be any side-effects during signing and notarization? The reason is it'd be a lot easier in my use case to be able to put content here instead of the Resources folder.

Hi Developers, I'm encountering persistent validation errors in Xcode 16.3 (16E140) on macOS 15.4.1 (24E263) with M1 when archiving and distributing a macOS app (Developer ID signing + notarization). App Structure: A native Swift/Obj-C wrapper app that launches a nested .app inside its Resources. The nested app is built with PyInstaller and includes: A Python core Custom C++ binaries Many bundled .so libraries (e.g., from OpenCV, PyQt/PySide) Issues During Validation: App Sandbox Not Enabled Error: App Sandbox missing for NestedApp.app/Contents/MacOS/NestedExecutable. Question: For Developer ID (not App Store), is sandboxing strictly required for nested PyInstaller apps? If the wrapper is sandboxed, must the nested app be as well? Given the PyInstaller app's nature (requiring broad system access), how should entitlements be managed? Upload Symbols Failed Errors for missing .dSYM files for: The nested app’s executable Custom C++ binaries .so files (OpenCV, PyQt, etc.) These are either third-party or built without DWARF data, making .dSYM generation impractical post-build. Question: Are these symbol errors critical for Developer ID notarization (not App Store)? Can notarization succeed despite them? Is lack of symbol upload a known limitation with PyInstaller apps? Any best practices?

Hi, I am facing an issue with login persistence using firebase, but basically, it seems that I need to ensure I enable the Keychain Sharing within the Identities capabilities, the problem is, it is not even on the list. Thank you much

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.

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

All libraries are getting rejected with errors like: not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs

Yes, this is very likely the completely wrong way to do things but I would like to ask regardless. Currently with windows/linux I can perform an in-situ upgrade of an application by performing a download of the binary 'foo' and then doing a rename-and-replace and subsequently requesting the licencee to restart the program and all is good. With macOS, as the binary is within the foo.app ( Contents/macOS/foo ) I imagine I cannot perform a similar operation without breaking the signing of the foo.app itself? ....or, can I individually sign the binary foo for macOS and perform the same type of operation? Download new foo as foo.new rename current foo.app/Content/macOS/foo -> foo.old rename foo.new -> foo Restart application Again, I know this is very likely an un-macOS way of performing the task but as you can imagine with supporting cross-platform development it's usually easier to maintain a consistent method even if it's "not ideal".

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?

I’ve developed a macOS app, but I’ve had trouble using a script to fully codesign it and package it into a .dmg file. I was only able to complete codesigning using the third-party app itself—not via command-line scripts. Is it possible to write a script that automates the entire process of codesigning the app? To provide the best user experience for those downloading the app outside of the Mac App Store, is it correct to first package it as a .app and then wrap that into a .dmg file for distribution? Currently, the app is available on the web as a .dmg. When downloaded, it appears in a folder and can be double-clicked to launch. However, macOS displays a warning that it was downloaded from the internet. Can I use a script to remove that quarantine warning? If possible, I’d appreciate a step-by-step explanation and a sample command-line script to: Codesign the app properly Package it into a signed .dmg Remove the quarantine attribute for local testing or distribution Is the reason I was only able to codesign it inside the third-party app due to how that app was built, or can this always be done from the command line?

Hi, I have created a conda python environment which I have packaged into a .tar.gz (using conda-pack) and which runs correctly when extracted (in this example, it only contains the scipy package). However, when I sign the necessary files within the environment (i.e. the binaries, the dylibs, the .so files), attempting to load scipy.sparse now fails with the error "mapped file has no cdhash, completely unsigned" about one of the .so files. Furthermore, I believe that this file does in fact have a cdhash. The signing process represented by my example below has been working for about a year, and I am unsure why it has suddenly stopped working. I am on a 2020 MacBook Pro with an i7 processor and running Sequoia 15.1.1. Here is a minimal example showing the creating of the conda environment, codesigning, and the error message. Many thanks in advance! # Create and activate conda env > conda create -y -n mwe_env python=3.10 > conda activate mwe_env # Verify scipy not initially installed (mwe_env) > python Python 3.10.16 (main, Dec 11 2024, 10:24:41) [Clang 14.0.6 ] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import scipy Traceback (most recent call last): File "<stdin>", line 1, in <module> ModuleNotFoundError: No module named 'scipy' (mwe_env) > pip install scipy Collecting scipy Downloading scipy-1.15.2-cp310-cp310-macosx_14_0_x86_64.whl.metadata (61 kB) Collecting numpy<2.5,>=1.23.5 (from scipy) Downloading numpy-2.2.4-cp310-cp310-macosx_14_0_x86_64.whl.metadata (62 kB) Downloading scipy-1.15.2-cp310-cp310-macosx_14_0_x86_64.whl (25.1 MB) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 25.1/25.1 MB 17.3 MB/s eta 0:00:00 Downloading numpy-2.2.4-cp310-cp310-macosx_14_0_x86_64.whl (7.0 MB) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 7.0/7.0 MB 16.4 MB/s eta 0:00:00 Installing collected packages: numpy, scipy Successfully installed numpy-2.2.4 scipy-1.15.2 (mwe_env) > python Python 3.10.16 (main, Dec 11 2024, 10:24:41) [Clang 14.0.6 ] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import scipy.sparse >>> # success! # Package conda env (mwe_env) > conda-pack --output mwe_env.tar.gz --name mwe_env Collecting packages... Packing environment at '/path/to/my/conda/envs/mwe_env' to 'mwe_env.tar.gz' [########################################] | 100% Completed | 7.8s (mwe_env) > conda deactivate > mkdir mwe_dir && cd mwe_dir > tar -xzvf ../mwe_env.tar.gz > source bin/activate (mwe_dir) > python Python 3.10.16 (main, Dec 11 2024, 10:24:41) [Clang 14.0.6 ] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import scipy.sparse >>> # success! # Sign the binaries and .dylibs and .so files (mwe_dir) > find bin -type f | xargs -n1 xcrun codesign -f -o runtime --timestamp --sign "Developer ID Application: MY_TEAM_ID" (mwe_dir) > find . -name "*.dylib" -o -name "*.so" -type f | xargs -n1 xcrun codesign -f -o runtime --timestamp --sign "Developer ID Application: MY_TEAM_ID" # the second command prints many lines saying it is "replacing existing signature" (mwe_dir) > python Python 3.10.16 (main, Dec 11 2024, 10:24:41) [Clang 14.0.6 ] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import scipy.sparse Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/__init__.py", line 315, in <module> from . import csgraph File "/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/csgraph/__init__.py", line 187, in <module> from ._laplacian import laplacian File "/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/csgraph/_laplacian.py", line 7, in <module> from scipy.sparse.linalg import LinearOperator File "/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/linalg/__init__.py", line 134, in <module> from ._eigen import * File "/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/__init__.py", line 9, in <module> from .arpack import * File "/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/arpack/__init__.py", line 20, in <module> from .arpack import * File "/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/arpack/arpack.py", line 50, in <module> from . import _arpack ImportError: dlopen(/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/arpack/_arpack.cpython-310-darwin.so, 0x0002): tried: '/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/arpack/_arpack.cpython-310-darwin.so' (code signature in <5DD8FC01-7360-3DB9-8273-C8A45ABB19A9> '/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/arpack/_arpack.cpython-310-darwin.so' not valid for use in process: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.), '/System/Volumes/Preboot/Cryptexes/OS/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/arpack/_arpack.cpython-310-darwin.so' (no such file), '/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/arpack/_arpack.cpython-310-darwin.so' (code signature in <5DD8FC01-7360-3DB9-8273-C8A45ABB19A9> '/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/arpack/_arpack.cpython-310-darwin.so' not valid for use in process: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.) # But: (mwe_dir) > xcrun codesign -dvvv /path/to/mwe_dir/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/arpack/_arpack.cpython-310-darwin.so Executable=/path/to/mwe_dir/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/arpack/_arpack.cpython-310-darwin.so Identifier=_arpack.cpython-310-darwin Format=Mach-O thin (x86_64) CodeDirectory v=20400 size=4318 flags=0x10000(runtime) hashes=129+2 location=embedded Library validation warning=OS X SDK version before 10.9 does not support Library Validation Hash type=sha256 size=32 CandidateCDHash sha256=816731ecd1ad01b38555cbfef8c000628696d0ca CandidateCDHashFull sha256=816731ecd1ad01b38555cbfef8c000628696d0ca53376aebf6fae28d8c02f519 Hash choices=sha256 CMSDigest=816731ecd1ad01b38555cbfef8c000628696d0ca53376aebf6fae28d8c02f519 CMSDigestType=2 CDHash=816731ecd1ad01b38555cbfef8c000628696d0ca Signature size=9000 Authority=Developer ID Application: MY_TEAM_ID Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=2 Apr 2025 at 16:24:52 Info.plist=not bound TeamIdentifier=MY_TEAM_ID Sealed Resources=none Internal requirements count=1 size=188

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 the gatekeeper area of blocking these additional executables. We get the following when trying to run those additional exes in any way: Trace/BPT trap: 5 We're using macdeployqt to finalize the bundle and bring in the correct packages - perhaps something it's doing is causing the additional executables to fail or we're missing an entitlement. We've submitted the app to TestFlights successfully even with these invalid executables to see if there was something the processing of the app would find but so far nothing. We've seen other example of applications with multiple executables in the same MacOS directory and are wondering what the difference is. Any hints or guidance would be great. Thank you!

We are using an app distributed via an iOS enterprise certificate. There is an exceptional user who could normally use the app signed with this certificate before upgrading to iOS 18. However, after updating to iOS 18 (currently on version 18.3), the app crashes immediately upon launch. Real-time logs indicate that the application fails to start. This issue is unique to this user, as other users on the same iOS 18.3 system do not experience the problem. console log

Background I've repeatedly run into codesigning (and missing provisioning profile) issues for my Ruby/Glimmer app and am looking for ways to troubleshoot this outside of Xcode. The app structure is as follows: PATHmanager.app └── Contents ├── Info.plist ├── MacOS │   └── PATHmanager ├── PkgInfo ├── Resources │   └── AppIcon.icns ├── _CodeSignature │   └── CodeResources └── embedded.provisionprofile Architecture I have a Mac mini Apple M2 Pro with macOS Ventura 13.4. Xcode is not used directly, but the underlying command line tools (e.g., codesign, productbuild, pkgutil, xcrun) are run from a custom Ruby script. xcodebuild -version Xcode 14.3.1 Build version 14E300c Questions Is the .app directory and file structure/naming sufficient? If not, can you point me in the direction of a minimal example that does not use Xcode? Info.plist is an XML text document (not binary), which I believe is in an acceptable format, but how do I lint this file and determine if it contains all of the necessary key/value pairs? <?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>CFBundleDevelopmentRegion</key> <string>en</string> <key>CFBundleDisplayName</key> <string>PATH manager</string> <key>CFBundleExecutable</key> <string>PATHmanager</string> <key>CFBundleIconFile</key> <string>AppIcon.icns</string> <key>CFBundleIdentifier</key> <string>com.chipcastle.pathmanager</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>PATHmanager</string> <key>CFBundlePackageType</key> <string>APPL</string> <key>CFBundleShortVersionString</key> <string>1.15</string> <key>CFBundleSupportedPlatforms</key> <array> <string>MacOSX</string> </array> <key>CFBundleVersion</key> <string>1.15</string> <key>ITSAppUsesNonExemptEncryption</key> <false/> <key>LSApplicationCategoryType</key> <string>public.app-category.developer-tools</string> <key>LSMinimumSystemVersion</key> <string>12.0</string> <key>LSUIElement</key> <false/> <key>NSAppTransportSecurity</key> <dict> <key>NSAllowsArbitraryLoads</key> <true/> </dict> <key>NSHumanReadableCopyright</key> <string>© 2025 Chip Castle Dot Com, Inc.</string> <key>NSMainNibFile</key> <string>MainMenu</string> <key>NSPrincipalClass</key> <string>NSApplication</string> </dict> </plist> PATHmanager is a Mach-O 64-bit executable arm64 file created by using Tebako. Does this executable need to be codesigned, or is codesigning the .app folder sufficient? Does the .app directory need an entitlements file? Here's how I codesign it: codesign --deep --force --verify --verbose=4 --options runtime --timestamp --sign 'Apple Distribution: Chip Castle Dot Com, Inc. (BXN9N7MNU3)' '/Users/chip/Desktop/distribution/PATHmanager.app' Does the PATHmanager binary need an entitlements file? Here's how I codesign it: codesign --deep --force --verify --verbose=4 --options runtime --timestamp --entitlements '/Users/chip/Desktop/PATHmanager.entitlements' --sign 'Apple Distribution: Chip Castle Dot Com, Inc. (BXN9N7MNU3)' '/Users/chip/Desktop/distribution/PATHmanager.app/Contents/MacOS/PATHmanager' How can I verify what entitlements, if any, are required for codesigning the binary? The PATHmanager.entitlements file is an XML text file containing only the following: <?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.app-sandbox</key> <true/> </dict> </plist> Is the embedded.provisionprofile necessary, and if so, how do I know determine if it matches the certificate or entitlements that I'm using? Additionally, is it named and located properly? I submitted this to the AppStore several weeks ago and the reviewer reported that the executable would not load on their machine (even though it worked on mine.) Is it better for me to release via TestFlight for testing, and if so, do I need to following a separate process for codesigning (i.e., using different entitlements, profiles, certs, etc) when doing so? I've been playing whack-a-mole with this for too long to mention and am hoping to nail down a better deployment flow, so any suggestions for improvement will be greatly appreciated. Thank you in advance.

The actual error: pkgbuild: error: Could not find appropriate signing identity for “Developer ID installer: My Name (DeveloperID)”. I'm trying to sign a program written with gfortran. The steps worked the last time (Mar 23) I built this code. The steps to error: a) xcrun notarytool store-credentials --apple-id "xxx" --team-id "yyy" Giving Profile Name zzz and App-specific password b) codesign --force --timestamp --options=runtime -s "Developer ID Application: My Name (yyy)" AppName c) pkgbuild --root ROOT --identifier org.aaa.bbb --version "1.1.1" --sign "Developer ID installer: My Name (yyy)" AppName.pkg ROOT contains the package contents At this point I get the error pkgbuild: error: Could not find appropriate signing identity for “Developer ID installer: My Name (yyy)” Are there steps that have changed. Any suggestions? Thanks, David

I'm currently befuddled by the entire signing and certificate process. I don't understand what I need, what the team admin needs to do, or how to go about doing it so that I can build the project. We've managed to have this working in the past but I guess the system has changed somewhat. Here's what we have going: A Unity project which hasn't changed from a few years ago. I build the project in unity, open the Xcode project and this: There's an issue with the Signing and Capabilities. If I choose automatic setup it shows an error saying that it requires a development team. I had the account admin add my Apple ID to the team so I'm not sure why that's an issue still. Do I need to pay the 99$ to be able to building Xcode? If I try to do it manually I select the provisioning profile that the account admin sent me and it auto selects the team associated with the provisioning profile I guess but then there's no singing certificate. The error says: There is no signing certificate "iOS Development" found. No "iOS Development" signing certificate matching team ID "V7D5YBZRMV" with a private key was found. So, if someone could explain to me like I'm 5 the entire signing and certificate process is and let me know what we're doing wrong with the team/provisioning profile/certificate setup I would be very much appreciative.

I suddenly started to receive the following email with the error in it stating that my uploaded app is not available to be used in TestFlight: ITMS-90886: 'Cannot be used with TestFlight because the signature for the bundle at “MyApp.app/Contents/PlugIns/MyAppWidgetExtension.appex” is missing an application identifier but has an application identifier in the provisioning profile for the bundle. Bundles with application identifiers in the provisioning profile are expected to have the same identifier signed into the bundle in order to be eligible for TestFlight.' It was all working fine and now I am not sure even where to start looking. Signing, provisioning and everything else is managed automatically.

App translocation, officially known as Gatekeeper path randomisation, comes up from time-to-time. The best resource to explain it, WWDC 2016 Session 706 What’s New in Security, is no longer available from Apple so I thought I’d post some notes here (r. 105455698 ). Questions or comments? Start a new thread here on DevForums, applying the Gatekeeper tag so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" App Translocation Notes Gatekeeper path randomisation, more commonly known as app translocation, is a security feature on macOS 10.12 and later. When you run a newly downloaded app, the system executes the app from a randomised path. This prevents someone from taking an app that loads code from an app-relative path and repackaging it to load malicious code. IMPORTANT The best way to prevent your app from being tricked into loading malicious code is to enable library validation. You get this by default once you enable the hardened runtime. Do not disable library validation unless your app needs to load in-process plug-ins from other third-party developers. If you have an in-process plug-in model, consider migrating to ExtensionKit. The exact circumstances where the system translocates an app is not documented and has changed over time. It’s best to structure your app so that it works regardless of whether it’s translocated or not. App Translocation Compatibility Most apps run just fine when translocated. However, you can run into problems if you load resources relative to your app bundle. For example, consider a structure like this: MyApp.app Templates/ letter.myapp envelope.myapp birthday card.myapp Such an app might try to find the Templates directory by: Getting the path to the main bundle Navigating from that using a relative path This won’t work if the app is translocated. The best way to avoid such problems is to embed these resources inside your app (following the rules in Placing Content in a Bundle, of course). If you need to make them easily accessible to the user, add your own UI for that. For a great example of this, run Pages and choose File > New. App Translocation Limits There is no supported way to detect if your app is being run translocated. If you search the ’net you’ll find lots of snippets that do this, but they all rely on implementation details that could change. There is no supported way to determine the original (untranslocated) path of your app. Again, you’ll find lots of unsupported techniques for this out there on the ’net. Use them at your peril! If you find yourself using these unsupported techniques, it’s time to sit down and rethink your options. Your best option here is to make your app work properly when translocated, as illustrated by the example in the previous section. App Translocation in Action The following steps explain how to trigger app translocation on macOS 13.0. Keep in mind that the specifics of app translocation are not documented and have changed over time, so you might see different behaviour on older or new systems: To see app translocation in action: Use Safari to download an app that’s packaged as a zip archive. My go-to choice for such tests is NetNewsWire, but any app will work. Safari downloads the zip archive to the Downloads folder and then unpacks it (assuming your haven’t tweaked your preferences). In Finder, navigate to the Downloads folder and launch the app. When Gatekeeper presents its alert, approve the launch. In Terminal, look at the path the app was launched from: % ps xw | grep NetNewsWire … /private/var/folders/wk/bqx_nk71457_g9yry9c_2ww80000gp/T/AppTranslocation/C863FADC-A711-49DD-B4D0-6BE679EE225D/d/NetNewsWire.app/Contents/MacOS/NetNewsWire Note how the path isn’t ~/Downloads but something random. That’s why the official name for this feature is Gatekeeper path randomisation. Quit the app. Use Finder to relaunch it. Repeat step 5: % ps xw | grep NetNewsWire … /private/var/folders/wk/bqx_nk71457_g9yry9c_2ww80000gp/T/AppTranslocation/C863FADC-A711-49DD-B4D0-6BE679EE225D/d/NetNewsWire.app/Contents/MacOS/NetNewsWire The path is still randomised. Quit the app again. Use the Finder to move it to the desktop. And relaunch it. And repeat step 5 again: % ps xw | grep NetNewsWire … /Users/quinn/Desktop/NetNewsWire.app/Contents/MacOS/NetNewsWire The act of moving the app has cleared the state that triggered app translocation.

This post is a ‘child’ of Resolving errSecInternalComponent errors during code signing. If you found your way here directly, I recommend that you start at the top. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Fixing an untrusted code-signing certificate If your code-signing identity is set up correctly, selecting its certificate in Keychain Access should display a green checkmark with the text “This certificate is valid”. If it does not, you need to fix that before trying to sign code. There are three common causes of an untrusted certificate: Expired Missing issuer Trust settings overrides Check for an expired certificate If your code-signing identity’s certificate has expired, Keychain Access shows a red cross with the text “… certificate is expired”. If you try to sign with it, codesign will fail like so: % codesign -s "Apple Development" -f "MyTrue" error: The specified item could not be found in the keychain. If you use security to list your code-signing identities, it will show the CSSMERR_TP_CERT_EXPIRED status: % security find-identity -p codesigning Policy: Code Signing Matching identities 1) 4E587951B705280CBB8086325CD134D4CDA04977 "Apple Development: …" (CSSMERR_TP_CERT_EXPIRED) 1 identities found Valid identities only 0 valid identities found The most likely cause of this problem is that… yep… your certificate has expired. To confirm that, select the certificate in Keychain Access and look at the Expires field. Or double click the certificate, expand the Details section, and look at the Not Valid Before and Not Valid After fields. If your code-signing identity’s certificate has expired, you’ll need to renew it. For information on how to do that, see Developer Account Help. If your certificate hasn’t expired, check that your Mac’s clock is set correctly. Check for a missing issuer In the X.509 public key infrastructure (PKI), every certificate has an issuer, who signed the certificate with their private key. These issuers form a chain of trust from the certificate to a trusted anchor. In most cases the trusted anchor is a root certificate, a certificate that’s self signed. Certificates between the leaf and the root are known as intermediate certificates, or intermediates for short. Your code-signing identity’s certificate is issued by Apple. The exact chain of trust depends on the type of certificate and the date that it was issued. For example, in 2022 Apple Development certificates are issued by the Apple Worldwide Developer Relations Certification Authority — G3 intermediate, which in turn was issued by the Apple Root CA certificate authority. If there’s a missing issuer in the chain of trust between your code-signing identity’s certificate and a trusted anchor, Keychain Access shows a red cross with the text “… certificate is not trusted”. If you try to sign with it, codesign will fail like so: % codesign -s "Apple Development" -f "MyTrue" MyTrue: replacing existing signature Warning: unable to build chain to self-signed root for signer "Apple Development: …" MyTrue: errSecInternalComponent The message unable to build chain to self-signed root for signer is key. If you use security to list your identities, it will not show up in the Valid identities only list but there’s no explanation as to why: % security find-identity -p codesigning Policy: Code Signing Matching identities 1) 4E587951B705280CBB8086325CD134D4CDA04977 "Apple Development: …" 1 identities found Valid identities only 0 valid identities found IMPORTANT These symptoms can have multiple potential causes. The most common cause is a missing issuer, as discussed in this section. Another potential cause is a trust settings override, as discussed in the next section. There are steps you can take to investigate this further but, because this problem is most commonly caused by a missing intermediate, try taking a shortcut by assuming that’s the problem. If that fixes things, you’re all set. If not, you have at least ruled out this problem. Apple publishes its intermediates on the Apple PKI page. The simplest way to resolve this problem is to download all of the certificates in the Apple Intermediate Certificates list and use Keychain Access to add them to your keychain. Having extra intermediates installed is generally not a problem. If you want to apply a more targeted fix: In Keychain Access, find your code-signing identity’s certificate and double click it. If the Details section is collapsed, expand it. Look at the Issuer Name section. Note the value in the Common Name field and, if present, the Organizational Unit field. For example, for an Apple Development certificate that’s likely to be Apple Worldwide Developer Relations Certification Authority and G3, respectively. Go to the Apple PKI and download the corresponding intermediate. To continue the above example, the right intermediate is labelled Worldwide Developer Relations - G3. Use Keychain Access to add the intermediate to your keychain. Sometimes it’s not obvious which intermediate to choose in step 4. If you’re uncertain, download all the intermediates and preview each one using Quick Look in the Finder. Look in the Subject Name section for a certificate whose Common Name and Organizational Unit field matches the values from step 3. Finally, double check the chain of trust: In Keychain Access, select your code-signing identity’s certificate and choose Keychain Access > Certificate Assistant > Evaluate. In the resulting Certificate Assistant window, make sure that Generic (certificate chain validation only) is selected and click Continue. It might seem like selecting Code Signing here would make more sense. If you do that, however, things don’t work as you might expect. Specifically, in this case Certificate Assistant is smart enough to temporarily download a missing intermediate certificate in order to resolve the chain of trust, and that’ll prevent you from seeing any problems with your chain of trust. The resulting UI shows a list of certificates that form the chain of trust. The first item is your code-signing identity’s certificate and the last is an Apple root certificate. Double click the first item. Keychain Access presents the standard the certificate trust sheet, showing the chain of trust from the root to the leaf. You should expect to see three items in that list: An Apple root certificate An Apple intermediate Your code-signing identity’s certificate If so, that’s your chain of trust built correctly. Select each certificate in that list. The UI should show a green checkmark with the text “This certificate is valid”. If you see anything else, check your trust settings as described in the next section. Check for a trust settings override macOS allows you to customise trust settings. For example, you might tell the system to trust a particular certificate when verifying a signed email but not when connecting to a TLS server. The code-signing certificates issued by Apple are trusted by default. They don’t require you to customise any trust settings. Moreover, customising trust settings might cause problems. If code signing fails with the message unable to build chain to self-signed root for signer, first determine the chain of trust per the previous section then make sure that none of these certificates have customised trust settings. Specifically, for each certificate in the chain: Find the certificate in Keychain Access. Note that there may be multiple instances of the certificate in different keychains. If that’s the case, follow these steps for each copy of the certificate. Double click the certificate to open it in a window. If the Trust section is collapsed, expand it. Ensure that all the popups are set to their default values (Use System Defaults for the first, “no value specified” for the rest). If they are, move on to the next certificate. If not, set the popups to the default values and close the window. Closing the window may require authentication to save the trust settings. Another way to explore trust settings is with the dump-trust-settings subcommand of the security tool. On a stock macOS system you should see this: % security dump-trust-settings SecTrustSettingsCopyCertificates: No Trust Settings were found. % security dump-trust-settings -d SecTrustSettingsCopyCertificates: No Trust Settings were found. That is, there are no user or admin trust settings overrides. If you run these commands and see custom trust settings, investigate their origins. IMPORTANT If you’re working in a managed environment, you might see custom trust settings associated with that environment. For example, on my personal Mac I see this: % security dump-trust-settings -d Number of trusted certs = 1 Cert 2: QuinnNetCA Number of trust settings : 10 … because my home network infrastructure uses a custom certificate authority and I’ve configured my Mac to trust its root certificate (QuinnNetCA). Critically, this custom trust settings are nothing to do with code signing. If you dump trust settings and see an override you can’t explain, and specifically one related to code-signing certificate, use Keychain Access to remove it. Revision History 2025-09-29 Added information about the dump-trust-settings command to Check for a trust settings override. Made other minor editorial changes. 2022-08-10 First posted.