It seems like something changed in the notarization in the last few days. I'm running the same build script that creates and notarize a DMG that contains a PKG with 4 plugins. Everything is signed correctly. No error anywhere in the notarization process.
Checking the status of the notarization, I get this:
Status: success
Status Code: 0
Status Message: Package Approved
Stapling returns this:
The staple and validate action worked!
Yet, if I check the PKG inside with this command:
spctl -a -vvv -t install
I get this output:
.pkg: rejected
source=Unnotarized Developer ID
origin=Developer ID Installer: My Company
This project was perfectly working a few weeks ago, and we have not changed a thing. Checking the notarization log, the only issue I see is this:
"issues": [
{
"severity": "warning",
"code": null,
"path": "Archive.dmg/Installer.pkg",
"message": "This archive is corrupt, and cannot be unpacked for analysis.",
"docUrl": null,
"architecture": null
}
]
But this warning is also present in past DMG/PKG thatare notarized and work as they should.
Another difference from previous logs is that I can only see one item in ticketContents, which is the DMG, while previously I could see two, both the DMG and the PKG.
Notarization
RSS for tagNotarization is the process of scanning Developer ID-signed software for malicious components before distribution outside of the Mac App Store.
Posts under Notarization tag
123 Posts
Sort by:
Post
Replies
Boosts
Views
Activity
I'm trying to notarize an Objective-C app I've written in Xcode 15. However, when I archive the app, it is listed as a "Generic Xcode Archive" instead of an "app archive", so it can't be validated/distributed.
I've tried following all the steps in this article: https://developer.apple.com/documentation/technotes/tn3110-resolving-generic-xcode-archive-issue
My skip_install is set to NO. My app's dependencies don't show up under "Targets" so I couldn't check the skip_install setting for them. My linked libraries don't use a headers build phase. My install_path is set to $(LOCAL_APPS_DIR).
Why am I not getting an "app archive"?
I have recently upgraded to macOS 14 and Xcode 15. I gather codesign --deep no longer works.
Do I have to explicitly codesign every file in my .app? There are several hundreds of them.
Also, I am able to successfully codesign my executable (MyApp.app/Contents/MacOS/MyExecutable), but when I upload for Notarization, it fails with "The signature of the binary is invalid.", identifying the executable specifically.
This used to work fine. Why is it failing now?
The notarytool service seems to be down, but "Developer ID Notarization Service" is green in the system-status. If I try to submit a DMG for notorization or even just try to get the history it gives this response:
Error: internalError(statusCode: Optional(500), strData: nil, jsonData: Optional(["errors": <__NSSingleObjectArrayI 0x60000331d020>(
{
code = "UNEXPECTED_ERROR";
detail = "<null>";
id = 7S3TTC4N54UMTGOEMVREFQPSNE;
links = "<null>";
status = 500;
title = "Uncaught server exception";
}
)
, "statusCode": 500])) Please try again at a later time.
Everything worked a couple weeks ago
Greetings to all. I have purchased my developer account and encountered an error message stating "Team is not yet configured for notarization" when attempting to sign my software. Despite my efforts to get in touch with Developer Programs over the past month through numerous phone calls and emails, the only response I receive is that they are unable to assist me at the moment. This situation has become quite distressing. We are encountering obstacles in releasing our software as Apple is impeding our progress. Users are experiencing an "unidentified developer" error message when trying to download it. I am unsure who to reach out to for assistance, especially when Apple support seems unresponsive despite being quick to accept payments.
We have developed an application in which we have a main application and there are several loadable bundles which are loaded from within the main application.
We archive the main application and generate the .app file. When we run the app, everything works fine and it loads the bundles.
But when notarise the main application, it stops loading the bundles. We think we will need to notarise the bundles as well but not able to find the ways to do it.
Any help will be very appreciated.
I am bundling my app in a .dmg that I made.
I signed it, notarized it and stapled it.
When I install it on a friends Mac, I get the error message,"
This error may occur if something went wrong when authenticating using Sign in with Apple
Error Code 1000 for Sign in with Apple refers to an unknown error that occurred authenticating your Apple ID. Please make sure that you have Two-Factor authentication enabled for your Apple ID.
Is this because his Apple ID has not got two factor enabled, or because my Dev account does not?
I read somewhere that two factor must be enabled for latest versions of Macs, but again, is this my Apple Dev ID, or their's?
I seems like a pretty common issue but i'll make a post about it specifically for what i'm seeing. Its my first time notarizing an app so maybe its something in my config, but i'm not seeing any errors.
For simplicity I cloned, built and signed the sample Electron Forge app following the steps on https://www.electronforge.io/ "Getting Started". The build zip is 90MB so its not that large. My production application will be DMG, but even that is stuck (Maybe because the zips before it are currently stuck)
Trying to manually notarize via notarytool just hangs. I used xcrun notarytool submit <Package> --keychain-profile "NotaryProfile" --wait
Running xcrun notarytool history --keychain-profile "NotaryProfile" outputs the following.
createdDate: 2023-09-06T14:49:59.810Z
id: 838c0903-d136-4241-be98-174152a7e3cf
name: my-new-app.zip
status: In Progress
--------------------------------------------------
createdDate: 2023-09-06T14:31:08.880Z
id: 1ce6ef46-8b09-4b20-9f61-81292b2dcbb9
name: my-new-app.zip
status: In Progress
--------------------------------------------------
createdDate: 2023-09-06T14:10:23.726Z
id: 71bc9206-036e-46c7-aadf-6bfaa4097743
name: my-new-app.zip
status: In Progress
--------------------------------------------------
createdDate: 2023-09-06T13:54:35.527Z
id: 7c7fd365-1f08-48c6-a314-3a1809019f9c
name: my-new-app.zip
status: In Progress
Its been about 7 hours since my first attempt.
I tried to pull logs by calling xcrun notarytool log --keychain-profile "NotaryProfile" aa6e9df3-ef62-4058-8bcc-683f015b412a but it seems like non exist yet.
Submission log is not yet available or submissionId does not exist
id: aa6e9df3-ef62-4058-8bcc-683f015b412a
Not sure whats going on, but its pretty far off from the time estimate of 5 - 45 minutes.
Any help is appreciated.
NotaryTool version is 1.0.0 (28)
I've been trying to notarize an installer (.pkg file) on a new laptop. Previous versions have been notarized successfully on a previous Mac.
However, in spite of having the required certificates (same as the old Mac, generated for the new Mac) the submission gets stuck at "In Progress".
Doing it multiple times (even hours apart) doesn't help.
Is there a FAQ / suggested list of steps to help resolve this issue?
Here's what I see:
xcrun notarytool history --keychain-profile "(my profile name)"
results in (problem started with v4, the first version I've tried on this new Mac):
createdDate: 2023-10-17T01:34:36.911Z
id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
name: xxxxxxxxxx-v4.pkg
status: In Progress
--------------------------------------------------
createdDate: 2023-10-17T01:33:59.191Z
id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
name: xxxxxxxxxx-v4.pkg
status: In Progress
--------------------------------------------------
createdDate: 2023-10-16T21:01:25.832Z
id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
name: xxxxxxxxxx-v4.pkg
status: In Progress
--------------------------------------------------
createdDate: 2023-10-16T19:57:44.776Z
id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
name: xxxxxxxxxx-v4.pkg
status: In Progress
--------------------------------------------------
createdDate: 2023-10-02T14:17:34.108Z
id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
name: xxxxxxxxxx-v3.pkg
status: Accepted
--------------------------------------------------
createdDate: 2023-09-28T14:04:46.211Z
id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
name: xxxxxxxxxx-v2.pkg
status: Accepted
--------------------------------------------------
createdDate: 2023-09-20T17:28:46.168Z
id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
name: xxxxxxxxxx-v1.pkg
status: Accepted
--------------------------------------------------
xcrun notarytool log xxxxxxxxxxxxxxxxxxxx --keychain-profile "(my profile name)" results in:
Submission log is not yet available or submissionId does not exist
id: xxxxxxxxxxxxxxxxxxxxxxxx
IMPORTANT altool is deprecated for the purposes of notarisation and will stop working on 1 Nov 2023 [1]. If you’re currently notarising with altool, switch to notarytool now. For specific advice on how to do this, see TN3147 Migrating to the latest notarization tool.
General:
DevForums tag: Notarization
WWDC 2018 Session 702 Your Apps and the Future of macOS Security
WWDC 2019 Session 703 All About Notarization
WWDC 2021 Session 10261 Faster and simpler notarization for Mac apps
WWDC 2022 Session 10109 What’s new in notarization for Mac apps — Amongst other things, this introduced the Notary REST API
Notarizing macOS Software Before Distribution documentation
Customizing the Notarization Workflow documentation
Resolving Common Notarization Issues documentation
Notary REST API documentation
TN3147 Migrating to the latest notarization tool technote
Fetching the Notary Log DevForums post
Q&A with the Mac notary service team Developer > News post
Notarisation and the macOS 10.9 SDK DevForums post
Testing a Notarised Product DevForums post
Notarisation Fundamentals DevForums post
The Pros and Cons of Stapling DevForums post
Many notarisation issues are actually code signing or trusted execution issue. For more on those topics, see Code Signing Resources and Trusted Execution Resources.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] See Apple notary service update.
I'm trying to notarize an Objective-C app I've written in Xcode 15. I've mostly been following this guide: https://scriptingosx.com/2021/07/notarize-a-command-line-tool-with-notarytool/.
I got the Developer ID Application and Developer ID Installer certificates from Apple developer. I made sure hardened runtime was on in Xcode and chose Developer ID Application under the signing settings before archiving and exporting. After setting up my notarytool profile, I used "xcrun notarytool submit" to submit for notarization.
This first attempt went over 24 hours and still said "In Progress" so I cancelled it.
For my second attempt I built an installer pkg for my app signed with my Developer ID Installer certificate. I submitted this for notarization with "xcrun notarytool submit" and after over 24 hours of "in progress' it returned "the request timed out".
What am I doing wrong in the sign/notarize process?
I tried to submit my app via the Notary Service with this command:
xcrun notarytool submit "${DMG_DIR}/${DMG_NAME}" --key "${APP_STORE_API_KEY}" --key-id "${KEY}" --issuer "${ISSUER}" --verbose
and I called the API to get the status of the submission, and it said it was rejected without any meta data.
I did codesign the app with this command:
codesign --force --timestamp --deep --sign "Developer ID Application: MY_NAME" "${DMG_DIR}/${DMG_NAME}"
Verify it with this command:
codesign -vvv --deep --strict "${DMG_DIR}/${DMG_NAME}"
The verification response:
/Users/runner/work/1/a/cli/osx-x64/{DMGFILE}.dmg: valid on disk
/Users/runner/work/1/a/cli/osx-x64/{DMGFILE}.dmg: satisfies its Designated Requirement
Verify the timestamp with this command and response:
Executable=/Users/runner/work/1/a/cli/osx-x64/{DMGFILE}.dmg
Identifier={IDENTIFIER}
Format=disk image
CodeDirectory v=20200 size=297 flags=0x0(none) hashes=1+6 location=embedded
Signature size=8975
Authority=Developer ID Application: MY_NAME
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Feb 14, 2024 at 7:40:35 PM
Info.plist=not bound
TeamIdentifier=TEAM_ID
Sealed Resources=none
Internal requirements count=1 size=172
I wonder if I missed any steps.
Thank you for the help.
Hi,
i'm trying to sign and notarize my app under company proxy, but I cannot reach timestamp service nor notarytool services. what I have to open on my firewall in order to reach them?
During Timestamp service call i'm receiving a generic "Timestamp service is not avaialble" but i know that out of company network i can reach it.
I am working on an open source app. I have been testing the package installer, and something unexpected is happening: the .pkg won't run on my test machine and will instead show a banner saying "myApp.app can't be opened because Apple cannot check it for malicious software"; nevertheless, if I wait some minutes, the installer will run just fine!
After reading through many of ekimo's posts, I assumed it may have something to do with stapler. I was not stapling my .dmg originally, so that's something I may be missing (my app is installed by a .pkg inside a .dmg). Nevertheless, the computer where I am testing the app has internet connection, meaning stapler should not even come into play.
Regardless, I decided to staple my .dmg. Running xcrun stapler staple -v myApp.dmg after notarizing produces this result:
builder ~ % xcrun stapler staple -v /Users/builder/Data/HEAD/installation/Packages/myApp.dmg
Processing: /Users/builder/Data/HEAD/installation/Packages/myApp.dmg
Properties are {
NSURLIsDirectoryKey = 0;
NSURLIsPackageKey = 0;
NSURLIsSymbolicLinkKey = 0;
NSURLLocalizedTypeDescriptionKey = "Disk Image";
NSURLTypeIdentifierKey = "com.apple.disk-image-udif";
"_NSURLIsApplicationKey" = 0;
}
Creating synthetic cdHash for unsigned disk image, myApp.dmg. Humanity must endure.
Signing information is {
cdhashes = (
{length = 20, bytes = 0xdd018313b1c574a403f01dccc96c21705987d76c}
);
"cdhashes-full" = {
2 = {length = 32, bytes = 0xdd018313 b1c574a4 03f01dcc c96c2170 ... 918d33f3 d5a74dc3 };
};
cms = {length = 0, bytes = 0x};
"digest-algorithm" = 2;
"digest-algorithms" = (
2
);
flags = 2;
format = "disk image";
identifier = ADHOC;
"main-executable" = "file:///Users/builder/Data/HEAD/installation/Packages/myApp.dmg";
source = "explicit detached";
unique = {length = 20, bytes = 0xdd018313b1c574a403f01dccc96c21705987d76c};
}
Stored Codesign length: 12 number of blobs: 0
Total Length: 12 Found blobs: 0
JSON Data is {
records = (
{
recordName = "2/2/dd018313b1c574a403f01dccc96c21705987d76c";
}
);
}
Headers: {
"Content-Type" = "application/json";
}
Domain is api.apple-cloudkit.com
Response is <NSHTTPURLResponse: 0x600003b85ba0> { URL: https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup } { Status Code: 200, Headers {
Connection = (
"keep-alive"
);
"Content-Encoding" = (
gzip
);
"Content-Type" = (
"application/json; charset=UTF-8"
);
Date = (
"Mon, 26 Feb 2024 15:34:15 GMT"
);
Server = (
"AppleHttpServer/78689afb4479"
);
"Strict-Transport-Security" = (
"max-age=31536000; includeSubDomains;"
);
"Transfer-Encoding" = (
Identity
);
Via = (
"xrail:st53p00ic-qujn15041902.me.com:8301:24R11:grp60,631194250daa17e24277dea86cf30319:59e17ac665e1de7388b8f4e69e92e383:defra2"
);
"X-Apple-CloudKit-Version" = (
"1.0"
);
"X-Apple-Edge-Response-Time" = (
99
);
"X-Apple-Request-UUID" = (
"9fc0fe2d-49fd-4e74-b718-660c56edb3bb"
);
"X-Responding-Instance" = (
"ckdatabasews:16306401:st42p63ic-ztfb05112901:8807:2409B432:afc827b7b1ebf24829e9c4856d4b69205f23804f"
);
"access-control-expose-headers" = (
"X-Apple-Request-UUID,X-Responding-Instance,Via"
);
"x-apple-user-partition" = (
63
);
} }
Size of data is 165
JSON Response is: {
records = (
{
reason = "Record not found";
recordName = "2/2/dd018313b1c574a403f01dccc96c21705987d76c";
serverErrorCode = "NOT_FOUND";
}
);
}
CloudKit query for myApp.dmg (2/dd018313b1c574a403f01dccc96c21705987d76c) failed due to "Record not found".
Could not find base64 encoded ticket in response for 2/dd018313b1c574a403f01dccc96c21705987d76c
The staple and validate action failed! Error 65
What does this show?
Thank you.
Hello! I'm dealing with a strange code signing issue which is preventing me from distributing a game through Steam. I'm able to sign and notarise the app in Xcode without any issues. I can verify that the app and all frameworks in /Contents/Frameworks/ are signed, and Gatekeeper allows the app to run without complaining.
$ spctl --assess -vvv ~/Temp/CodeSigningTest/GoodApp.app
/Users/ruairi/Temp/CodeSigningTest/GoodApp.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: Ruairi Dorrity (3F97UA4BF8)
$ codesign --verify -vvv ~/Temp/CodeSigningTest/GoodApp.app
--prepared:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/ogg.framework/Versions/Current/.
--validated:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/ogg.framework/Versions/Current/.
--prepared:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/mpg123.framework/Versions/Current/.
--validated:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/mpg123.framework/Versions/Current/.
--prepared:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/libmodplug.framework/Versions/Current/.
--validated:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/libmodplug.framework/Versions/Current/.
--prepared:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/freetype.framework/Versions/Current/.
--validated:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/freetype.framework/Versions/Current/.
--prepared:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/Lua.framework/Versions/Current/.
--validated:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/Lua.framework/Versions/Current/.
--prepared:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/vorbis.framework/Versions/Current/.
--validated:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/vorbis.framework/Versions/Current/.
--prepared:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/OpenAL-Soft.framework/Versions/Current/.
--validated:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/OpenAL-Soft.framework/Versions/Current/.
--prepared:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/theora.framework/Versions/Current/.
--validated:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/theora.framework/Versions/Current/.
--prepared:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/love.framework/Versions/Current/.
--validated:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/love.framework/Versions/Current/.
--prepared:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/SDL2.framework/Versions/Current/.
--validated:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/SDL2.framework/Versions/Current/.
/Users/ruairi/Temp/CodeSigningTest/GoodApp.app: valid on disk
/Users/ruairi/Temp/CodeSigningTest/GoodApp.app: satisfies its Designated Requirement
However, if I zip the app and upload it to Steam, the app that the Steam client downloads is blocked by Gatekeeper ("damaged and can't be opened") and re-running the above commands shows that the code signing seal has been broken somehow on the downloaded app:
$ spctl --assess -vvv ~/Temp/CodeSigningTest/BadApp.app
/Users/ruairi/Temp/CodeSigningTest/BadApp.app: cannot find code object on disk
$ codesign --verify -vvv ~/Temp/CodeSigningTest/BadApp.app
/Users/ruairi/Temp/CodeSigningTest/BadApp.app: code object is not signed at all
In subcomponent: /Users/ruairi/Temp/CodeSigningTest/BadApp.app/Contents/Frameworks/love.framework
The second command can be re-run, showing a seemingly random framework from /Contents/Frameworks/ each time e.g.
$ codesign --verify -vvv ~/Temp/CodeSigningTest/BadApp.app
/Users/ruairi/Temp/CodeSigningTest/BadApp.app: code object is not signed at all
In subcomponent: /Users/ruairi/Temp/CodeSigningTest/BadApp.app/Contents/Frameworks/ogg.framework
Further investigation shows that these frameworks are now unsigned, when they were signed before uploading and downloading:
$ codesign --verify -vvv ~/Temp/CodeSigningTest/BadApp.app/Contents/Frameworks/ogg.framework
/Users/ruairi/Temp/CodeSigningTest/BadApp.app/Contents/Frameworks/ogg.framework: code object is not signed at all
$ codesign --verify -vvv ~/Temp/CodeSigningTest/BadApp.app/Contents/Frameworks/love.framework
/Users/ruairi/Temp/CodeSigningTest/BadApp.app/Contents/Frameworks/love.framework: code object is not signed at all
...
$ codesign --verify -vvv ~/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/ogg.framework
/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/ogg.framework: valid on disk
/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/ogg.framework: satisfies its Designated Requirement
$ codesign --verify -vvv ~/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/love.framework
/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/love.framework: valid on disk
/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/love.framework: satisfies its Designated Requirement
I'm stumped as to what's happening here. Is is possible that the app is being modified being the scenes by Steam, which breaks the code signing? This seems unfathomable because it would surely break code signing on every Mac game on Steam, but I really can't understand what else would be going on. I'm sure I need to expand my knowledge on code signing; any pointers, suggestions or assistance is greatly appreciated! Thank you!
Recently, I completed development on an app that I hope to upload to Kickstarter.
I am unsure whether Apple Developer Program Membership incorporates signage and notarization fees.
In short, to package my app, will I need to find $99, or $300?
Thanks in advance for any advice.
Regards,
Lar
hi, team,
we used the py2app to build the mac app, the app works well before the codesign.
But when I codesign it with the --options runtime the app can't startup.
with the below error:
/petoi-mac-app/Petoi\ Desktop\ App.app/Contents/MacOS/Petoi\ Desktop\ App ; exit;
Traceback (most recent call last):
File "/Petoi Desktop App.app/Contents/Resources/__boot__.py", line 147, in <module>
_setup_ctypes()
File "/petoi-mac-app/Petoi Desktop App.app/Contents/Resources/__boot__.py", line 140, in _setup_ctypes
from ctypes.macholib import dyld
File "<frozen importlib._bootstrap>", line 983, in _find_and_load
File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 668, in _load_unlocked
File "<frozen importlib._bootstrap>", line 638, in _load_backward_compatible
File "ctypes/__init__.pyc", line 551, in <module>
File "ctypes/__init__.pyc", line 273, in _reset_cache
MemoryError
2024-02-21 19:57:09.168 Petoi Desktop App[93968:1375266] Launch error
2024-02-21 19:57:09.168 Petoi Desktop App[93968:1375266] Launch error
See the py2app website for debugging launch issues
But if I removed the --options runtime I got the Notarizing Error below.
{
"severity": "error",
"code": null,
"path": "PetoiDesktopInstaller.pkg/PetoiDesktopInstaller.pkg Contents/Payload/Applications/Petoi Desktop App.app/Contents/MacOS/Petoi Desktop App",
"message": "The executable does not have the hardened runtime enabled.",
"docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087724",
"architecture": "x86_64"
}
I am looking forward to your insightful reply.
I just tried submitting an app to be notarized. This app is actually only used by me internally (but I have other apps this question would be relevant to) and I can't submit for notarization. I get the following error:
"Hardened Runtime is not enabled."
Is the Hardened Runtime now required? I know it used to be optional (I believe the last time I submitted an app update a few months ago outside the Mac App Store I got no such error).
This post is part of a cluster of posts related to the trusted execution system. 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"
Resolving Code Signing Crashes on Launch
A code signing crash has the following exception information:
Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid))
IMPORTANT Most developers never see a code signing crash because they use Xcode to build and sign their product. Xcode’s code signing infrastructure detects problems that could cause a code signing crash, and its automatic code signing fixes them for you! If you’re having problems with code signing crashes and you can use Xcode but aren’t, consider making the switch Xcode.
The most common code signing crash is a crash on launch. To confirm that, look at the thread backtraces:
Backtrace not available
If you see valid thread backtraces this is not a crash on launch. Go back to Resolving Trusted Execution Problems and read through the Code Signing Crashes After Launch section.
If you see no thread backtraces, your code didn’t run at all. The trusted execution system has blocked it. In most cases there is some evidence of the problem in the system log. For example:
type: error
time: 2022-05-19 06:29:17.640331 -0700
process: taskgated-helper
subsystem: com.apple.ManagedClient
category: ProvisioningProfiles
message: com.example.apple-samplecode.OverClaim: Unsatisfied entitlements: com.apple.overclaim
This indicates that the OverClaim app, with bundle ID com.example.apple-samplecode.OverClaim, claimed a restricted entitlement, com.apple.overclaim, that wasn’t authorised by a provisioning profile.
For more information about provisioning profiles, see TN3125 Inside Code Signing: Provisioning Profiles. Specifically, the Entitlements on macOS section discusses the concept of restricted entitlements. For general information about the system log, see Your Friend the System Log.
Normalise the Entitlements Property List
Entitlement property list files look like text and so it’s tempting to edit them with a text editor. This can lead to all sorts of problems. If you have code whose entitlements property list contains comments, non-Unix line endings, or other weird formatting, the trusted execution system may block it. To avoid such problems, normalise your entitlements property list before passing it to codesign. For example:
% plutil -convert xml1 MyApp.plist
% codesign -s III --entitlements MyApp.plist MyApp.app
Problems like this typically show up on older systems. Modern systems use DER-encoded entitlements, as discussed in The future is DER section of TN3125.
A related gotcha is line breaks. Consider this entitlements property list file:
% cat MyApp.plist
…
<plist version="1.0">
<dict>
<key>
com.apple.security.cs.disable-library-validation</key>
<true/>
</dict>
</plist>
This is a valid property list but it doesn’t do what you think it does. It looks like it claims the com.apple.security.cs.disable-library-validation entitlement but in reality it claims \ncom.apple.security.cs.disable-library-validation. The system treats the latter as a restricted entitlement and thus requires it to be authorised by a profile. Of course no such profile will authorise that entitlement, and so the app is blocked by the trusted execution system.
Similarly, consider this:
% cat MyApp.plist
…
<plist version="1.0">
<dict>
<key> com.apple.security.cs.disable-library-validation</key>
<true/>
</dict>
</plist>
This claims com.apple.security.cs.disable-library-validation, note the leading space, and that’s also blocked by the trusted execution system.
Check for Unauthorised Entitlements
Sometimes the system log may not make it obvious what’s gone wrong. It may be easier to work this out by looking at the built program. The most common cause of problems like this is the app claiming a restricted entitlement that’s not authorised by a provisioning profile.
To start your investigation, dump the entitlements to check for restricted entitlements:
% codesign -d --entitlements - "OverClaim.app"
…/OverClaim.app/Contents/MacOS/OverClaim
[Dict]
[Key] com.apple.application-identifier
[Value]
[String] SKMME9E2Y8.com.example.apple-samplecode.OverClaim
[Key] com.apple.developer.team-identifier
[Value]
[String] SKMME9E2Y8
[Key] com.apple.overclaim
[Value]
[Bool] true
[Key] com.apple.security.get-task-allow
[Value]
[Bool] true
In this case all the entitlements except com.apple.security.get-task-allow are restricted.
Note If there are no restricted entitlements, something else has gone wrong. Go back to Resolving Trusted Execution Problems and look for other potential causes.
Now check that the provisioning profile was embedded correctly and extract its payload:
% ls -l "OverClaim.app/Contents/embedded.provisionprofile"
… OverClaim.app/Contents/embedded.provisionprofile
% security cms -D -i "OverClaim.app/Contents/embedded.provisionprofile" -o "OverClaim-payload.plist"
Check that the profile applies to this app by dumping the com.apple.application-identifier entitlement authorised by the profile:
% /usr/libexec/PlistBuddy -c "print :Entitlements:com.apple.application-identifier" OverClaim-payload.plist
SKMME9E2Y8.com.example.apple-samplecode.*
This should match the com.apple.application-identifier entitlement claimed by the app.
Repeat this for all the remaining restricted entitlements:
% /usr/libexec/PlistBuddy -c "print :Entitlements:com.apple.developer.team-identifier" OverClaim-payload.plist
SKMME9E2Y8
% /usr/libexec/PlistBuddy -c "print :Entitlements:com.apple.overclaim" OverClaim-payload.plist
Print: Entry, ":Entitlements:com.apple.overclaim", Does Not Exist
In this example the problem is the com.apple.overclaim entitlement, which is claimed by the app but not authorised by the profile. If that’s the case for your program, you have two choices:
If you program doesn’t need this entitlement, update your code signing to not claim it.
If you program relies on this entitlement, update your profile to authorise it.
The entitlement allowlist in the profile is built by the Apple Developer website based on the capabilities enabled on your App ID. To change this allowlist, modify your App ID capabilities and rebuild your profile. Some capabilities are only available on some platforms and, within that platform, for some distribution channels. For these details for macOS, see Developer Account Help > Reference > Supported capabilities (macOS). Some capabilities require review and approval by Apple. For more on this, see Developer Account Help > Reference > Provisioning with capabilities.
Check for Required Entitlements
If your app claims any restricted entitlements, it must also claim the com.apple.application-identifier entitlement, with its value being your app’s App ID. macOS uses this value to confirm that the embedded provisioning profile is appropriate for your app. Without this, macOS might not use this profile, which means there’s nothing to authorise your app’s use of restricted entitlements, which prevents your app from launching.
IMPORTANT macOS 12 and later will use an embedded provisioning profile even if the app doesn’t claim the com.apple.application-identifier entitlement. So, if your app works on macOS 12 and later but fails on macOS 11, this is likely the cause.
If you claim the com.apple.application-identifier entitlement then I recommend that you also claim the com.apple.developer.team-identifier entitlement. That’s what Xcode does, and my experience is that it’s best to stay on that well-trodden path.
Check the Signing Certificate
If your program’s entitlements look good, the next most likely problem is that your program was signed by a signing identity whose certificate is not authorised by the profile. To debug this, first extract the certificate chain from your program:
% codesign -d --extract-certificates=signed-with- "OverClaim.app"
…
% for i in signed-with-* ; do mv "${i}" "${i}.cer" ; done
The first certificate is the one that matters:
% certtool d "signed-with-0.cer"
Serial Number : 53 DB 60 CC 85 32 83 DE 72 D9 6A C9 8F 84 78 25
…
Subject Name :
Other name : UT376R4K29
Common Name : Apple Development: Quinn Quinn (7XFU7D52S4)
OrgUnit : SKMME9E2Y8
Org : Quinn Quinn
Country : US
…
Now check this against each of the certificates authorised by the profile. Start by extracting the first one:
% plutil -extract DeveloperCertificates.0 raw -o - OverClaim-payload.plist | base64 -D > "authorised0.cer"
% certtool d "authorised0.cer"
Serial Number : 46 A8 EF 2C 52 54 DE FD D1 76 9D 3A 41 7C 9E 43
…
Subject Name :
Other name : UT376R4K29
Common Name : Mac Developer: Quinn Quinn (7XFU7D52S4)
OrgUnit : SKMME9E2Y8
Org : Quinn Quinn
Country : US
…
That’s not a match. So try the next one:
% plutil -extract DeveloperCertificates.1 raw -o - OverClaim-payload.plist | base64 -D > authorised1.cer
% certtool d "authorised1.cer"
Serial Number : 53 DB 60 CC 85 32 83 DE 72 D9 6A C9 8F 84 78 25
…
Subject Name :
Other name : UT376R4K29
Common Name : Apple Development: Quinn Quinn (7XFU7D52S4)
OrgUnit : SKMME9E2Y8
Org : Quinn Quinn
Country : US
…
This matches, which means the profile applies to this code.
IMPORTANT When checking for a match, look at the Serial Number field. Don’t just rely on the Common Name field. A common mistake is to have two signing identities whose certificates have identical common names but the profile only lists one of them.
If you get to the end of the list of certificate list in the profile and don’t find the certificate that the program was signed with, you know what the problem is: Your program is signed with a signing identity whose certificate is not listed in its profile. To fix this, either:
Reconfigure your code signing to use a signing identity whose certificate is listed.
Or update the profile to include the certificate of the signing identity you’re using.
Check for Expiration
If your certificates aren’t the problem, check that nothing has expired. Start with the certificate from the app’s signature:
% certtool d "signed-with-0.cer"
Serial Number : 53 DB 60 CC 85 32 83 DE 72 D9 6A C9 8F 84 78 25
…
Not Before : 10:52:56 Apr 21, 2022
Not After : 10:52:55 Apr 21, 2023
…
Also check the expiry date on the profile:
% plutil -extract ExpirationDate raw -o - OverClaim-payload.plist
2023-04-21T11:02:58Z
If either has expired, update it and re-sign your product.
IMPORTANT Developer ID-signed code and installers include a secure timestamp. When the system checks the expiry date on a Developer ID certificate, it only checks that the certificate was valid at the time that the code was signed, base on that secure timestamp. Thus, an old Developer ID-signed app will continue to run after it’s certificate has expired.
To learn more about secure timestamps, see TN3161 Inside Code Signing: Certificates.
Check the Supported Devices
If everything else checks out, the last thing to check is that the profile authorises the code to run on this machine. There are two cases here:
Developer ID profiles authorise the code on all machines.
Other profiles authorise the code on a specific list of machines.
If you think you have a Developer ID profile, confirm that by looking for the ProvisionsAllDevices property:
% plutil -extract "ProvisionsAllDevices" xml1 -o - "OverClaim-payload.plist"
… No value at that key path or invalid key path: ProvisionsAllDevices
If that’s not the case, get the ProvisionedDevices property and verify that the current machine’s provisioning UDID is listed there:
% plutil -extract "ProvisionedDevices" xml1 -o - "OverClaim-payload.plist"
…
<array>
…
<string>A545CA26-80D7-5B38-A98C-530A798BE342</string>
…
</array>
</plist>
% system_profiler SPHardwareDataType
…
Provisioning UDID: A545CA26-80D7-5B38-A98C-530A798BE342
…
If you get to the end any everything looks OK, your provisioning profile is not the cause of this crash. Return to Resolving Trusted Execution Problems for more suggestions.
Revision History
2024-02-20 Added the Check for Required Entitlements section. Added a link to TN3161. Fixed the Developer Account Help links.
2022-06-08 Added the Normalise the Entitlements Property List section.
2022-05-20 First posted.
I am facing a problem in electron's apps notarisations. I have submitted my NodeJS code and the validations takes a long time.
Hope, anyone can clarify why it takes so long.