Error Failed To Staple Your Application With Code 65
Eugene Hill
We build everything via a big Xcode workspace and xcodebuild command. To notarize, I create a zip archive of the resulting xcarchive, then I upload this zip archive to Apple server with altool --notarize-app.
Should be noted that MyApplication.app and MyApplication.app/Contents/MacOS/MyApplication are in the final Apple logs (as all other Mach-O files in the archive). And [sha256] is a real valid sha256 value (just redacted there).
Should be noted too that if I zip directly MyApplication.app and upload this zip on Apple server with altool, then everything works as expected (I'm able to staple the notarization ticket to the application). So it seems to fail only when I notarize xcarchive, and only for .app bundles. I would still want to not do that, as each upload and notarization take time, so if it can be done in a single big step, it would be better.
If you're looking at the developer_log.json file for your successful notarization (altool --notarization-info ), there's a section for ticketContents. This shows the cdhashes for everything that was successfully notarized and can be stapled. Confirm that the cdhash for MyApplication.app (codesign -dvvv MyApplication.app) matches the cdhash for MyApplication.app in the ticketContents. Any changes to the code signature (including exporting in the organizer) will create a new cdhash.
Information about automating the export process can be found in Customizing the Notarization Workflow. There's also an entire script that can be used in a single big step to export everything and notarize it as part of an Archive phase post-action in Customizing the Xcode Archive Process.
-> If I install the resulting package on a machine which is offline in 10.14.5, then the kext doesn't load, as the notarization ticket is not stapled to it and macOS is not able to contact Apple servers to verify. Stapling the notarization ticket to the pkg doesn't staple notarization tickets to the content of the pkg (I tested). And this is a problem for us.
If I try to modify the pkg to staple the notarization ticket to each element (by using pkgutil --expand etc.), then it modify my pkg, and invalidate the signature, so I need to resign, and notarize again so I can staple a notarization ticket to the pkg itself (it doesn't seem necessary for now to staple the notarization ticket to the pkg, but I guess it will at some time, so I would like to be a bit proactive).
So it was simpler to notarize the .xcarchive, staple the ticket to elements inside, create the pkg, sign it, notarize it (and notarize its content again, but it's an involuntary side effect in this scheme), and staple the ticket to the pkg itself. This way everything is 1/ notarized 2/ stapled.
That being said, even if I notarize only the pkg itself, I'm not able to staple notarization ticket to the application neither (I have updated the ticket). I get the exact same error (stapler error 65).
We are a bit moving away from the original subject, but my first guess was "if I notarize my pkg and staple the notarization ticket to the pkg, then the installer will automatically validate / staple notarization ticket to inner elements, like my kext, when installing".
So it's what I tried to do in the first place : I notarized only the pkg, and then stapled the notarization ticket to the pkg. But then the kext was not loadable when installing on an offline machine (it was working fine when online).
- Notarize the final pkg (this step is not really necessary in this scenario, but my idea was that it will be necessary, soon or later, to have notarized pkg files to be able to install them - some proactivity).
If it's supposed to work without stapling notarization tickets to inner elements of the pkg (only the pkg itself), then I guess there is a bug somewhere ? I see there is something about this in the 10.14.5b5 release note (related to ticket 50205533). I guess it's related to my scenario ? When I tested it, the resulting pkg was not downloaded (so no quarantine flag).
We, independent developers, who run our own businesses are not getting paid by the our. The waste of time due to this half-backed notarization thing has been unspeakable. Which for independent developers directly transpaltes into loss of income.
I am trying to package a Mac Electron app using Electron Forge capabilities. Code signing works fine, but there is a problem with notarising. I get"Finalizing package Failed to staple your application with code: 65". The notarize component of my forge.config.js is:
I provide my Apple ID and the app password in a terminal message together with npm run make. This worked in May this year, but now not. In a JSON response, I do get " reason = "Record not found". Anyone else had this issue and resolved it?
I tried to notarize (Code sign) Electron Node.js app using Electron forge to submit it to Mac App Store (MAS) by following the option Using an app-specific password mentioned in Electron forge official guide, but encountering error - "Failed to staple your application with code: 66. Cannot download ticket. CDHash must be set."
3) Run command for notarization:- xcrun altool --notarize-app --primary-bundle-id "com.def.ghi" --username "developer ID" --password "related password" --file codesign_utilities.zip. I am able to notarize the zip file.
SUPPORTED FILE FORMATS stapler works only with UDIF disk images, signed "flat" installer packages, and certain code-signed executable bundles such as ".app". Passing an unsigned "flat" installer package or an unsigned executable bundle in path to stapler is considered an error.
First up, I strongly recommend that you not use your Downloads folder for day-to-day work. Downloads is protected by MAC, and that can cause all sorts of weird problems. See On File System Permissions for more about MAC.
In most cases, however, you can staple your ticket by adopting the right packaging format. Mac users expect to receive their software in one of three containers: zip, disk image, or installer package. Two out of three of those support stapling. So, my advice is that you package your tool into a container that supports stapling, notarise that container, and then staple that.
One last note: Some users attempt to run command-line tools by double clicking them in the Finder. Doing this triggers a Gatekeeper bug; see the Tool Blocked by Gatekeeper section of Resolving Gatekeeper Problems. If you think your users are likely to do this, you can avoid this bug by distributing your tool in an installer package.
Now, I'm trying to convert my exe file (python compiled for MacOS) in an App, so I can avoid the Gatekeeper issue. Following instruction I read, I create a directory (named MyApp.app) inside Desktop folder. on the said MyApp.app dir, I create a Contents directory, and inside the latter, MacOS (where the exe file was placed) and Resources (where the icon was placed). Inside the Contents directory, besides Dirs MacOS and Resources, I put the file Info.plist.
One more:I tested my App in a completely new Mac (I meant, new to the App, actually it was an Intel Non T2 Mac build in year 2017). To my surprise, the non-signed app runs perfectly while the Signed-Notarized one throw an execution error complaining about the signature (both surpass Gatekeeper with no complain whatsoever from it side). However, in an another non T2 Mac affiliated to my icloud address, both worked well at the first time (likewise, surpassing Gatekeeper).
So far, the only complain from Gatekeeper came from an Intel T2, in which case, I needed to disabled it. But once I did that, both the signed-Notarized and the non-signed run perfectly well as expected. (tests on M1/M2 pending). [note: when I say non-signed, I meant non signed according to Apple rules. PyInstaller somehow sign the file at the time of compilation (is a very limited signature, much less informative compared to Apple's)].
What I am trying to achieve is to distribute a single file compiled exe (originally a python script compiled using pyinstaller) directly to certain customers. (it is an exe file, that runs by open it or double click on it from Finder).
So, the idea is to have the said exe as an App available to download or otherwise, send it over to selected users. We already have a Zip file with the exe inside, duly signed and notarized (I meant, we went to the process to get an accepted notarization from Apple using exclusively cmd tools).
When I say "convert it to an app" (sorry for not use the appropriate language is that is the case) I meant to have the app opened by double clicking in the downloaded exe file (once the downloaded Zip is opened). Please, point to me to info on how to do this properly. On the other hand, as using zip files are not compatible with stapling, we would prefer to distribute the app using pkg or dmg, whichever is appropriate and more straight forward. (Any hints will be highly appreciated!)