I am trying to get a PKG installer through the Apple codesign and notarytool process. When I submit the PKG installer I get a status message of "Invalid" and when I review the log file it has 2 errors. For "status summary" it says: "Archive contains critical validation errors", and for "message" it says" "The binary is not signed".
The installer contains a flat file that is installed in the "Users/Shared" folder via the PKG installer.
Here are the steps I've taken to get the installer through the codesign and notarytool process.
codesign the file that's placed in the "Users/Shared" folder:
codesign --options=runtime --sign 'Developer ID Application: XYZ' -v /Users/.../Documents/folder/"flat file"
which I get a message saying "signed generic".
Create the PKG installer with the signed "flat file".
Sign the PKG installer containing the signed "flat file":
codesign --options=runtime --sign 'Developer ID Application: XYZ' -v /Users/.../Documents/folder/"flat file"
which I get a message saying "signed generic".
Submit the PKG file with notarytool:
xcrun notarytool submit /Users/.../Documents/folder/"flat file" --verbose --apple-id username --password password --team-id ID# --progress
It completes and provides the submission ID.
I check the status and get the error message that it's invalid.
When I check the full details via the log I get the error messages mentioned above.
What am I missing or failing to do?
General
RSS for tagDemystify code signing and its importance in app development. Get help troubleshooting code signing issues and ensure your app is properly signed for distribution.
Post
Replies
Boosts
Views
Activity
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.
Can you please revoke my developer id application and installer certs? So i may recreate.
I deleted the private key by mistake before realizing i cannot recreate everything using the developer website portal. I dont have macos backup or did i backup my certs with attached pkey.
I just did not realize this was important until now.
Please help as Im now blocked. I opened a case too but i have not yet got a response. its been 3 days now. case id: 20000093632858
Hi,
I'm doing Java 22 experiments with open source package "wgpu-macos-aarch64-release" on my Mac M3.
This library contains a .dylib file and a .a file.
In Java you can load native dynamic libraries using JNI. I used that in the past. Now in MacOS 15 this stopped working.
Currently, I compile my Java file and run the binary file on the command line, including the library directory. The application would load the library from that directory. This should normally works but the library is not loaded.
After some investigation it seems the .dylib is rejected by MacOS.
Calling
spctl --assess --verbose=4 libwgpu_native.dylib
gives
libwgpu_native.dylib: rejected
without any extra reason message.
Using
sudo xattr -rd com.apple.quarantine libwgpu_native.dylib
doesn't solve the problem.
I also can't "accept" it in "Privacy & Security" because it's run as a command line call.
I know that code signing should be done for "complete" applications. But these are just experiments and working with single dynamic libraries.
How should this be done, to be able to load those libraries in a Java command line program? Or in general, how can you load an unsigned dylib in an application (apart from using Java as a tool).
Kr,
J
Can someone please describe what is necessary to perform signing using codesign in a system that runs as LaunchDaemon.
All workarounds like placing the codesigning cert + private key a custom keychain and unlock it in the session of the LaunchDaemon doesn't work anymore on Sequoia.
Or are there alternatives for signing MachO binaries without codesign?
I regularly see folks run into problems with their Developer ID signing identities. Historically I pointed them to my posts on this thread, but I’ve decided to collect these ideas together in one place.
If you have questions or comments, start a new thread here on DevForums and tag it with Developer ID so that I see it.
IMPORTANT Nothing I write here on DevForums is considered official documentation. It’s just my personal ramblings based on hard-won experience. There is a bunch of official documentation that covers the topics I touch on here, including:
Xcode documentation
Xcode Help
Developer Account Help
Developer > Support > Certificates
For a lot more information about code signing, see the Code Signing Resources pinned post.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
The Care and Feeding of Developer ID
Most Apple signing assets are replaceable. For example, if you accidentally lose access to your Apple Development signing identity, it’s a minor inconvenience. Just use the Developer website to revoke your previous certificate and create a replacement. Or have Xcode do that for you.
IMPORTANT If you don’t understand the difference between a certificate and a digital identity, and hence signing identity, read Certificate Signing Requests Explained before reading this post.
Some signing assets are precious. Losing access to such assets has significant consequences.
Foremost amongst those are Developer ID signing identities. These allow you to sign Mac products that ship independently. Anyone with access to your Developer ID signing identity can sign code as you. This has a number of consequences, both for you and for your relationship with Apple.
Identify a Developer ID Signing Identity
A Developer ID signing identity consists of two parts: the certificate and the private key. There are two different flavours, identifiable by the subject name in the certificate:
Developer ID Application — This is named Developer ID Application: TTT, where TTT identifies your team. Use this to sign code and disk images.
Developer ID Installer — This is named Developer ID Installer: TTT, where TTT identifies your team. Use this to sign installer packages.
Note If you do KEXT development, there’s a third flavour, namely a KEXT-enabled Developer ID Application signing identity. For more details, see KEXT Code Signing Problems.
This post focuses on traditional signing identities, where you manage the private key. Xcode Cloud introduced cloud signing, where signing identities are “stored securely in the cloud”. These identities have the Managed suffix in Certificates, Identifiers, and Profiles. For example, Developer ID Application Managed is the cloud signing equivalent of Developer ID Application. To learn more about cloud signing, watch WWDC 2021 Session 10204 Distribute apps in Xcode with cloud signing. To identify these certificates ‘in the wild’, see Identifying a Cloud Managed Signing Certificate.
Limit Access to Developer ID
Anyone with your Developer ID signing identity can sign code as you. Given that, be careful to limit access to these signing identities. This is true both for large organisations and small developers.
In a large organisation, ensure that only folks authorised to ship code on behalf of your organisation have access to your Developer ID signing identities. Most organisations have some sort of release process that they use to build, test, and authorise a release. This often involves a continuous integration (CI) system. Restrict CI access to only those folks involved in the release process.
Even if you’re a small developer with no formal release process, you can still take steps to restrict access to Developer ID signing identities. See Don’t Leak Your Private Key, below.
In all cases, don’t use your Developer ID signing identities for day-to-day development. That’s what Apple Development signing identities are for.
Create Developer ID Signing Identities as the Account Holder
Because Developer ID signing identities are precious, the Developer website will only let the Account Holder create them. For instructions on how to do this, see Developer Account Help > Create certificates > Create Developer ID certificates. For more information about programme roles, see Developer > Support > Program Roles.
IMPORTANT In an Organization team it’s common for the Account Holder to be non-technical. They may need help getting this done. For hints and tips on how to avoid problems while doing this, see Don’t Lose Your Private Key and Don’t Leak Your Private Key, both below.
Limit the Number of Developer ID Signing Identities You Create
Don’t create Developer ID signing identities unnecessarily. Most folks only need to create one. Well, one Developer ID Application and maybe one Developer ID Installer. A large organisation might need more, perhaps one for each sub-unit, but that’s it.
There are two reasons why this is important:
The more you have, the more likely it is for one to get into the wrong hands. Remember that anyone with your Developer ID signing identity can sign code as you.
The Developer website limits you to 5 Developer ID certificates.
Note I can never remember where this limit is actually documented, so here’s the exact quote from this page:
You can create up to five Developer ID Application certificates and up to five Developer ID Installer certificates using either your developer account or Xcode.
Don’t Lose Your Private Key
There are two standard processes for creating a Developer ID signing identity:
Developer website — See Developer Account Help > Create certificates > Create Developer ID certificates.
Xcode — See Xcode Help > Maintaining signing assets > Manage signing certificates.
Both processes implicitly create a private key in your login keychain. This makes it easy to lose your private key. For example:
If you do this on one Mac and then get a new Mac, you might forget to move the private key to the new Mac.
If you’re helping your Organization team’s Account Holder to create a Developer ID signing identity, you might forget to export the private key from their login keychain.
It also makes it easy to accidentally leave a copy of the private key on a machine that doesn’t need it; see Don’t Leak Your Private Key, below, for specific advice on that front.
Every time you create a Developer ID signing identity, it’s a good idea to make an independent backup of it. For advice on how to do that, see Back Up Your Signing Identities, below.
That technique is also useful if you need to copy the signing identity to a continuous integration system.
If you think you’ve lost the private key for a Developer ID signing identity, do a proper search for it. Finding it will save you a bunch of grief. You might be able to find it on your old Mac, in a backup, in a backup for your old Mac, and so on. For instructions on how to extract your private key from a general backup, see Recover a Signing Identity from a Mac Backup.
If you’re absolutely sure that you previous private key is lost, use the Developer website to create a replacement signing identity.
If the Developer website won’t let you create any more because you’ve hit the limit discussed above, talk to Developer Programs Support. Go to Apple > Developer > Contact Us and follow the path Development and Technical > Certificates, Identifiers, and Provisioning Profiles.
Don’t Leak Your Private Key
Anyone with your Developer ID signing identity can sign code as you. Thus, it’s important to take steps to prevent its private key from leaking.
A critical first step is to limit access to your Developer ID signing identities. For advice on that front, see Limit Access to Developer ID, above.
In an Organization team, only the Account Holder can create Developer ID signing identities. When they do this, a copy of the identity’s private key will most likely end up in their login keychain. Once you’ve exported the signing identity, and confirmed that everything is working, make sure to delete that copy of the private key.
Some organisations have specific rules for managing Developer ID signing identities. For example, an organisation might require that the private key be stored in a hardware token, which prevents it from being exported. Setting that up is a bit tricky, but it offers important security benefits.
Even without a hardware token, there are steps you can take to protect your Developer ID signing identity. For example, you might put it in a separate keychain, one with a different password and locking policy than your login keychain. That way signing code for distribution will prompt you to unlock the keychain, which reminds you that this is a significant event and ensures that you don’t do it accidentally.
If you believe that your private key has been compromised, follow the instructions in the Compromised Certificates section of Developer > Support > Certificates.
IMPORTANT Don’t go down this path if you’ve simply lost your private key.
Back Up Your Signing Identities
Given that Developer ID signing identities are precious, consider making an independent backup of them. To back up a signing identity to a PKCS#12 (.p12) file:
Launch Keychain Access.
At the top, select My Certificates.
On the left, select the keychain you use for signing identities. For most folks this is the login keychain.
Select the identity.
Choose File > Export Items.
In the file dialog, select Personal Information Exchange (.p12) in the File Format popup.
Enter a name, navigate to your preferred location, and click Save.
You might be prompted to enter the keychain password. If so, do that and click OK.
You will be prompted to enter a password to protect the identity. Use a strong password and save this securely in a password manager, corporate password store, on a piece of paper in a safe, or whatever.
You might be prompted to enter the keychain password again. If so, do that and click Allow.
The end result is a .p12 file holding your signing identity. Save that file in a secure location, and make sure that you have a way to connect it to the password you saved in step 9.
Remember to backup all your Developer ID signing identities, including the Developer ID Installer one if you created it.
To restore a signing identity from a backup:
Launch Keychain Access.
Choose File > Import Items.
In the open sheet, click Show Options.
Use the Destination Keychain popup to select the target keychain.
Navigate to and select the .p12 file, and then click Open.
Enter the .p12 file’s password and click OK.
If prompted, enter the destination keychain password and click OK.
Alternatively, Xcode has a feature to export and import your developer account, including your Developer ID signing identities. Do this using the action menu in Xcode > Settings > Accounts. For the details, see Xcode Help > Maintaining signing assets > Export signing certificates and provisioning profiles.
Recover a Signing Identity from a Mac Backup
If you didn’t independently backup your Developer ID signing identity, you may still be able to recover it from a general backup of your Mac. To start, work out roughly when you created your Developer ID signing identity:
Download your Developer ID certificate from the Developer website.
In the Finder, Quick Look it.
The Not Valid Before field is the date you’re looking for.
Now it’s time to look in your backups. The exact details depend on the backup software you’re using, but the basic process runs something like this:
Look for a backup taken shortly after the date you determined above.
In that backup, look for the file ~/Library/Keychains/login.keychain.
Recover that to a convenient location, like your desktop. Don’t put it in ~/Library/Keychains because that’ll just confuse things.
Rename it to something unique, like login-YYYY-MM-DD.keychain, where YYYY-MM-DD is the date of the backup.
In Keychain Access, choose File > Add Keychain and, in the resulting standard file panel, choose that .keychain file.
On the left, select login-YYYY-MM-DD.
Chose File > Unlock Keychain “login-YYYY-MM-DD“.
In the resulting password dialog, enter your login password at the date of the backup.
At the top, select My Certificates.
Look through the list of digital identities to find the Developer ID identity you want. If you don’t see the one you’re looking for, see Further Recovery Tips below.
Export it using the process described at the start of Back Up Your Signing Identities.
Once you’re done, remove the keychain from Keychain Access:
On the left, select the login-YYYY-MM-DD keychain.
Choose File > Delete Keychain “login-YYYY-MM-DD”.
In the confirmation alert, click Remove Reference.
The login-YYYY-MM-DD.keychain is now just a file. You can trash it, keep it, whatever, at your discretion.
This process creates a .p12 file. To work with that, import it into your keychain using the process described at the end of Back Up Your Signing Identities.
IMPORTANT Keep that .p12 file as your own independent backup of your signing identity.
Further Recovery Tips
If, in the previous section, you can’t find the Developer ID identity you want, there are a few things you might do:
Look in a different backup.
If your account has more than one keychain, look in your other keychains.
If you have more than one login account, look at the keychains for your other accounts.
If you have more than one Mac, look at the backups for your other Macs.
The login-YYYY-MM-DD keychain might have the private key but not the certificate. Add your Developer ID certificate to that keychain to see if it pairs with a private key.
Revision History
2025-02-20 Added some clarification to the end of Don’t Leak Your Private Key.
2023-10-05 Added the Recover a Signing Identity from a Mac Backup and Further Recovery Tips sections.
2023-06-23 Added a link to Identifying a Cloud Managed Signing Certificate.
2023-06-21 First posted.
Hi everyone. Sorry if this is not an appropriate forum section for this question. I'm making a game engine and it doesn't launch on my colleague's MacBook, although it does launch on mine.
There's an application file, let's say, Sample.app. And along with it in the same folder there's Engine.dylib. If we look at the app-file structure, the executable file's path is Contents/MacOS/Sample. So for the executable file the library is located at the path ../../../Engine.dylib. But when my colleague runs the Sample.app file, he gets an error "Library not loaded: @executable_path/../../../Engine.dylib". Although the path is correct and on my MacBook it works. Are there any ideas how to fix it?
I have a .NET 6 application that runs in the background. The installer is a .pkg file built using a third-party tool called "Packages".
All .dylib and executable files are codesigned before packaging. The resulting .pkg file is notarized.
The app uses these entitlements:
com.apple.security.cs.allow-jit
com.apple.security.cs.allow-unsigned-executable-memory
com.apple.security.cs.allow-dyld-environment-variables
com.apple.security.cs.disable-library-validation
The app is built on a macbook Air 2015 running macOS 12.6 and it works without issues on that machine.
On a macbook Pro M3 running macOS 14.6.1 the app fails to run even though the installation itself is successful.
The only logs that I was able to find are related to syspolicyd (4 warnings):
Unable to apply protection to app: 45, PST: (vuid: A78FF6C2-08D5-4DCC-B946-8836251AA0E7), (objid: 1873967), (team: (null)), (id: (null)), (bundle_id: (null))
Failed to register app bundle for protection: 45, PST: (vuid: A78FF6C2-08D5-4DCC-B946-8836251AA0E7), (objid: 1873967), (team: (null)), (id: (null)), (bundle_id: (null))
scan failed, finishing evaluation : PST: (vuid: A78FF6C2-08D5-4DCC-B946-8836251AA0E7), (objid: 1873967), (team: (null)), (id: (null)), (bundle_id: (null))
Terminating process due to Gatekeeper rejection: 95158,
Unfortunately, verification commands such as
sudo codesign --verify --deep --strict -vvv MyApplication.App
spctl -a -vvv -t install MyApplicationInstaller.pkg
do not indicate any issues.
Are there any additional steps that need to be performed in order for my app to work properly on newer machines?
Hello!
I've just recently discovered LaunchCodeRequirement API and I'm exploring how it works compared to existing alternatives available for macOS versions below 14.4.
Some questions I have with regards to safety of older and newer APIs examining the given example:
func runProcess(executableURL: URL) throws {
let process = Process()
process.executableURL = executableURL
if #available(macOS 14.4, *) {
process.launchRequirement = try LaunchCodeRequirement.allOf {
ValidationCategory(.developerID)
SigningIdentifier("some-signing-identifier")
TeamIdentifier("some-team-identifier")
}
} else {
try secStaticCodeCheckValidity(executableURL) // Point #1
}
do {
try process.run() // Point #2
if #available(macOS 14.4, *) {
// process.launchRequirement should take care of the process
// and kill it if launchRequirement constraint is not satisfied
} else {
try secCodeCheckValidity(process.processIdentifier) // Point #3
}
process.waitUntilExit()
} catch {
process.terminate()
throw error
}
// Point #4
guard process.terminationReason == .exit else {
throw SomeError()
}
}
let requirement =
"""
anchor apple generic
and identifier = "some-signing-identifier"
and certificate 1[field.1.2.840.113635.100.6.2.6]
and certificate leaf[field.1.2.840.113635.100.6.1.13]
and certificate leaf [subject.OU] = "some-team-identifier"
"""
func secStaticCodeCheckValidity(_ executableURL: URL) throws {
// Init SecStaticCode from `executableURL`
// Init SecRequirement from `requirement`
let flags = SecCSFlags(rawValue: kSecCSBasicValidateOnly)
guard SecStaticCodeCheckValidityWithErrors(code, flags, secRequirement, nil) == errSecSuccess else {
throw CodeSignError()
}
}
func secCodeCheckValidity(_ processIdentifier: Int32) {
// Init SecCode from `processIdentifier`
// Init SecRequirement from `requirement`
guard SecCodeCheckValidityWithErrors(code, [], secRequirement, nil) == errSecSuccess else {
throw CodeSignError()
}
}
Before macOS 14.4+ flow
There's still a small chance that between checking executable binary codesign requirement (Point #1) and launched process' one (Point #3) the binary could be replaced with something malicious and even get some CPU between Points #2 and #3 so technically it can't be 100% safe. Is that a correct statement? Any advices on making it safer?
macOS 14.4+ flow
Now let's see how launchRequirement is better. I guess initialized launchRequirement gets evaluated on running the process (Point #2).
What does it exactly check? Executable at URL before launching the process (as OnDiskConstraint) or launched process (as ProcessConstraint)?
Is there any chance the process gets some CPU before it's killed in case of failed codesign check?
Any way to distinguish between codesign requirement termination and other reasons at point #4? It returns SIGKILL (9) as terminationStatus but it's not precise enough to be sure it was killed due to failed requirement check. I guess newer SecStaticCodeCheckValidityWithOnDiskRequirement & SecCodeCheckValidityWithProcessRequirement are the same as SecStaticCodeCheckValidityWithErrors & SecCodeCheckValidityWithErrors but a little simpler and can't be used as a 'more secure' way of validating codesign requirement.
Thanks,
Pavel
Hi,
I have a project that integrates the Firebase SDK via SPM as a dependency of an internal Swift Package:
My app ⟶ My Library ⟶ Firebase SDK
The project builds successfully and can be archived locally ✅. The uploaded .ipa is valid and gets published 🚀.
However, we are now trying to automate the release process using Xcode Cloud, but the iOS Archive action is failing ❌ on Xcode Cloud.
The logs show the following error ⬇️:
error: exportArchive codesign command failed (/Volumes/workspace/tmp/XcodeDistPipeline/XcodeDistPipeline.~~~oomCvM/Root/Payload/base-ios.app/Frameworks/FirebaseAnalytics.framework: replacing existing signature
/Volumes/workspace/tmp/XcodeDistPipeline/XcodeDistPipeline.~~~oomCvM/Root/Payload/base-ios.app/Frameworks/FirebaseAnalytics.framework: invalid or corrupted code requirement(s)
Requirement syntax error(s):
line 1:178: unexpected token: <COMPANY_NAME>
)
** EXPORT FAILED **
I have been researching this issue for a while and have tried several solutions to fix it, but with no luck. Even though the error points to a specific library—the Firebase SDK—I don’t believe Firebase is the root cause. There were related issues in the past, but those were already fixed by the Firebase team, and as I mentioned, the project archives correctly when built locally.
On the other hand, the error states:
line 1:178: unexpected token: <COMPANY_ACRONYM>
This makes me wonder if there’s an issue parsing our Team Name during the re-signing process, as it contains special characters ":
"name": "Apple Distribution: Company Full Name "COMPANY_ACRONYM""
I am a new macOS developer, and the codesign issue is persistent. I've been trying to resolve it for days. There are two issues:
1.) When downloading and installing frameworks, they are not showing up in Xcode templates.
2.) Regarding codesigning, even though I've installed it on my external drive and placed it in various locations (Library, Templates, Frameworks, Application Contents, macOS Templates and Frameworks) and added through General Libraries in Xcode, persistently encountering issues. I'm experiencing a codesign problem. I've cleaned the build, cleared derived data, downloaded certificates, added them to the access key, and linked the binary. However, the issue persists. Please help me, as this is making the process much more difficult. I've been stuck on this for weeks.
I am using matlab to create an application (.app) using matlab application compiler.
Along with that, I use matlab to create an installer for that.
Unfortunately, the installer is in (.app) format. So do some custom things to install the dependencies and copying my application to Applications folder.
I am able to sign the original application with Developer ID application certificate.
But I am not able to sign the installer in .app format with Developer ID installer certificate.
Is there any flag in any signing executable that allows me to use Developer ID installer certificate to sign .app file instead of typical (.pkg/.dmg)?
Any help would be much appreciated.
After I upgraded to macOS 15.3, all of my current Xcode project have the signing issue, I spent half day and I didn't make any progress, I tried two projects, one is Swift AppKit App calling one C++ dylib, another one is a pure Swift AppKit app, when I build, there will be error:
Warning: unable to build chain to self-signed root for signer "Apple Development: Steven Tang (XXXXX)"
/Volumes/TwoTSSD/steventang/Library/Developer/Xcode/DerivedData/ImageEnhancement-ddbilgyraofrdyfeljyuknusunza/Build/Products/Release/ImageEnhancement.app: errSecInternalComponent
I tried remove account, add account back in Xcode, none of it worked, also tried ChatGPT's WWDR updating and it won't help.
We are using SHC to compile on macOS to convert the .sh script to a binary file. This binary file is then digitally signed by the Apple developer account and then notarised. After that, it will work on the same system where we follow this process. But if we share this file to another system, then it gets quarantined (com.apple.quarantine) while downloading.
Is there any way to prevent it by getting quarantine on another system or something I'm missing, any clues?
iPad(第10世代、iOS v18.1)でMDMを使用してWi-Fiを設定すると、「ネットワーク「SSID名」に接続できない」という問題が発生しています。
この件についてアドバイスをいただければ幸いです。
私が取った手順は次のとおりです。
1.iPadをWi-Fiに接続し、Wi-Fi情報(SSID、ユーザー名、パスワード)をカスタム属性値としてMDMに登録します。
2. MDMから、Wi-Fiプロファイルをデバイスに配布します。
3.Wi-Fiプロファイルがデバイスにインストールされ、その後、ネットワークは自動的に切断されます。
ネットワークに再接続 4.To、OS設定の「Wi-Fi > My Network」に表示されているSSIDをタップしてください。
5.次の証明書画面で、「信頼」ボタンをタップします。
ここで、「ネットワーク「SSID名」に接続できません」というエラーが発生しました。
Appleサポートの提案に基づいて、以下を確認しました。しかし、問題はありません。
1.ルーターの電源がオンになっており、デバイスが通信範囲内にあります。
他のデバイスはWi-Fiに接続できるので問題ありません。
2.Wi-Fiがオンになり、ネットワークが認識されていることを確認します。
Wi-Fiが「オン」で、ネットワークが認識されます。
3.入力画面が表示された場合は、Wi-Fiパスワードを入力します。
入力画面が表示されません。
4.Wi-Fiネットワークに問題がないことを確認します。
接続されているWi-Fiネットワークの名前の下にWi-Fi警告/エラーは表示されません。
5.ケーブルと接続状態を確認します。
他のデバイスはWi-Fiに接続できるので問題ありません。
6.iPadを再起動します。
iPadを再起動しました。しかし、問題は解決しませんでした。
OS:iPadOS18.1
デバイス:iPad第10世代
We are trying to get much more serious about our ability to audit signed code and trace it back to a signing event. We have a signing service that includes a bit of client code that provides a CryptoTokenKit extension to expose the signing certificate to codesign and Xcode. The private keys are held by the signing service and access is strictly controlled.
The CTK extension is given a message/digest to sign, and from reading TN 3126, I believe this is representative of the code directory. For an audit trail, we can record some metadata about the signing request, such as Git repository, branch, commit SHA, etc., but the only value linked to the thing being signed is this blob.
Later, if we have an app and want to link it back to the signing event, I can't figure out how to find this blob. It's not the CDHash or any other value I see in the output of codesign -d -vvvvvv.
is there a way to recreate that blob given a signed artifact?
I've noticed that NSTaks has this property as of macOS 14.4
@property (nullable, copy) NSData *launchRequirementData API_AVAILABLE(macos(14.4)) API_UNAVAILABLE(ios, watchos, tvos, visionos);
It has no documentation whatsoever. Even google search has no clue. Does this have anything to do with code signature requirements validation? Any explanations and examples would be appreciated!
I am trying to code sign an application which relies on many python libraries to run. For background knowledge, the .app was created with a —onefile command on Visual Studio.
I code signed my application itself using
codesign --deep --force --verify --timestamp --sign "Developer ID Application: Issey Yohannes (GL5BCCW69X)" /Users/isseyyohannes/Desktop/Automated\ ALGORA.app
However, when I try to run the application the error shows in terminal as follows
[PYI-16345:ERROR] Failed to load Python shared library '/var/folders/g9/2zbc7y_97xxbq7bnc301nnyc0000gn/T/_MEI6keRcA/Python': dlopen: dlopen(/var/folders/g9/2zbc7y_97xxbq7bnc301nnyc0000gn/T/_MEI6keRcA/Python, 10): no suitable image found. Did find:
/var/folders/g9/2zbc7y_97xxbq7bnc301nnyc0000gn/T/_MEI6keRcA/Python: code signature in (/var/folders/g9/2zbc7y_97xxbq7bnc301nnyc0000gn/T/_MEI6keRcA/Python) not valid for use in process using Library Validation: mapped file has no Team ID and is not a platform binary (signed with custom identity or adhoc?)
/var/folders/g9/2zbc7y_97xxbq7bnc301nnyc0000gn/T/_MEI6keRcA/Python: stat() failed with errno=1
Through some external tools, I was able to narrow the issue as follows
Hardened Runtime Restriction: Your application is attempting to load a shared library (Python) at runtime, but the library is either: Not properly signed with the same Team ID as your app. Not marked as a valid platform binary. macOS requires all loaded libraries to comply with its code-signing and runtime security policies.
Any insight is much appreciated.
Short description of the issue/suggestion:
After upgrading to MacOS Sequoia and being required to code sign and notarize my app, cannot launch app even though code sign and notarization pass
Please tell us about your environment:
MacBookPro
Chip Apple M2 Max
32 GB
JavaPackager version: 1.7.6
OS version: macOS Sequoia 15.0.1
JDK version: jdk-1.8
Build tool: Maven
Steps to reproduce the issue:
-DMG Maven Build of Spring Boot /Java (version 8) application with "fvarrui" JavaPackager plugin using default universalJavaApplicationStub. Code signing and Notarization / Stapling PASS and App installs in Application folder, however cannot launch App. Although code sign and notarization pass, it is interesting that in the build output, prior to it submitting to Apple, there is an error stating that the App code sign could not be replaced.
What is the expected behavior?
-App launches when double clicking the application icon
What have you tried to resolve / workaround the issue?
-Install via package rather than DMG - same result
-Can launch App by opening up the app Content/MacOS folder and clicking directly on the universalJavaApplicationStub. Note requires that you allow it to run within the Security and Privacy settings.
codesign --verify --deep --verbose force1.app
force1.app: valid on disk
force1.app: satisfies its Designated Requirement
spctl -a -vvv force1.app
Info.plist.txt
pom.xml.txt
f
Build Output abridged.txt
o
SysConsoleOutput.txt
r
ce1.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: Neal Hartmann (JPFYU53MK9)
Hi,
For the purposes of iteration speed in development builds, on an iPhone in development mode, I am attempting to use hot reloaded dylibs. The goal is that the app is rarely fully restarted and small code changes can be applied quickly, drastically reducing iteration speed.
For this purpose I have a socket server on my Mac that sends changed dylibs to my app on my iPhone. This works great on Mac, however on iOS i am running into codesigning problems.
I am using the following to codesign the dylib:
codesign -f -s *** --timestamp=none testlibrary-ios.dylib
I am placing the downloaded dylib in this folder:
const char* cachedirectoryPath = [NSSearchPathForDirectoriesInDomains(NSCachesDirectory, NSUserDomainMask, YES)[0] UTF8String];
dlopen gives me the following error:
dlopen(/var/mobile/Containers/Data/Application/67A3D31B-6F72-4939-9E7F-665FC78CDC61/Library/Caches/testlibrary-ios.dylib, 0x000A): tried: '/usr/lib/system/introspection/testlibrary-ios.dylib' (no such file, not in dyld cache), '/var/mobile/Containers/Data/Application/67A3D31B-6F72-4939-9E7F-665FC78CDC61/Library/Caches/testlibrary-ios.dylib' (code signature invalid in <78A101AD-D756-3526-8754-8B7F4925DE90> '/private/var/mobile/Containers/Data/Application/67A3D31B-6F72-4939-9E7F-665FC78CDC61/Library/Caches/testlibrary-ios.dylib' (errno=1) sliceOffset=0x00000000, codeBlobOffset=0x0000C2E0, codeBlobSize=0x00004990),
....
Is loading a dylib like this on iPhones in development mode possible?
Any idea what is going wrong with codesigning or installing the dylib?
(Obviously this code is never deployed in an app that goes on the AppStore)