Stapling Error 65 (Applescript app)

Can you comment further on the seeming conflict between what TN2206 says about using

--deep

and this suggestion?

Sure.

--deep

is a shortcut. It tells

codesign

to search for nested code and sign that exactly like the top-level code is signed. Sometimes that shortcut works just fine, but in some cases it fails. And some of those failures are horrible (like misidentifying nested code) and others are not a big deal (like applying entitlements to nested shared libraries; entitlements only make sense on executables and thus applying them to non-executable code is pointless and misleading, although not actively harmful).

Personally, I might use

--deep

for a quick hack but, if I’m setting up signing for a real product, I avoid it.

The issue I'm getting at is that adding

--deep

fixes … the same issue with

Script Debugger.plist

files, which have also historically been saved in

Contents/

.

I’d have to look at that specific issue in more depth before I can offer definitive advice.

And I see that

codesign

actually returned this error:

I don’t see an error there at all?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

> I don’t see an error there at all?

The termination status is 0, but what I posted is output to standardOut -- but only if I use --deep or if I sign the .wflow file first. And when it is output, spctl follows up with a rejection.

I'm just wondering how it is that apps spctl rejects are successfully uploaded and notarized. Maybe I'm worrying over nothing, and should just skip the spctl check. But I'm surprised, and it's the first reference I've seen to "source=Unnotarized Developer ID".

PS: I realise I updated to 10.14.5 today. Could that be the source of what I'm seeing with spctl?

Just an update: yes, I think what I'm seeing is a result of moving to 10.14.5. Presumably my spctl test is now performing the test that Gatekeeper is now performing, which means it's going to fail (at least with a hardened runtime app) until an app has been notarized. Surprising, but it makes sense. The issue of --deep and/or signing the .wflow files appears to have been a red herring.

I am trying to follow same process.

Running on 10.14.5

After stapling .app file with this output:

The staple and validate action worked!

When I check the .app file:

MacBook-Pro:dmg raulsanchez$ spctl -a -t exec -vvv Time\ Doctor\ 2.app/
Time Doctor 2.app/: accepted
origin=Developer ID Application: R Rawson (XXXXXXX)

What am I missing? Could you help please?

Thanks

If the stapling worked, I don't see any problem there.

Hi, Quinn,

I'm currently seeing exactly the same problem, and saw that you said it should be fixed now... but I'm still seeing the error 65 here.

I'm going to try thinning the applet, as we have no need to run it on 32-bit systems, but if this is a bug and it's back, I thought you should be aware.

I don't know if this can be of any help to others but I got the same stapling "error 65" in the following case

1. I created a DMG containing a classical bundle "myTest.app"
2. I successfully notarized the .dmg file
3. I got the "Error 65" when trying to staple it.

Processing: /Users/xxxx/Development/myTest_Install.dmg
CloudKit query for myTest_Install.dmg (2/aaf85e0a1c60c86705e9a8880ebe1ad4cd32bf56) failed due to "Record not found".
Could not find base64 encoded ticket in response for 2/aaf85e0a1c60c86705e9a8880ebe1ad4cd32bf56
The staple and validate action failed! Error 65.

I ultimately found was that the error was due "myTest.app" not being notarized !!!!

Come on Apple, instead of an error message that only aliens can understand it would not be too difficult to give us something more helpful!

All the best