Stapling a notarized dotnet app fails with code 65

Question

azw OP

Created Aug ’21

Replies 1

Boosts 0

Participants 2

I have an Avalonia application I want to distribute in-house. (Avalonia is a crossplatform GUI based on dotnet)

I followed the guide here: (https://docs.avaloniaui.net/docs/distribution-publishing/macos)

My notarization succeeds and I can get the notarization info using xcrun altool --notarization-info UUID -u myappleid

No errors getting notarization info.

          Date: 2021-08-18 07:29:13 +0000
          Hash: d1e8825c6571fff0bbcd11c5496b2a84ac1ad8b8a62b77771cde7a0eca286de9
    LogFileURL: <Log URL>
   RequestUUID: <UUID>
        Status: success
   Status Code: 0
Status Message: Package Approved

If I run codesign -dvvv "/Path/to/my app.app" I can see

Executable=/Path/to/my app.app/Contents/MacOS/my app
Identifier=com.my.app
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20500 size=1126 flags=0x10000(runtime) hashes=24+7 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=3e5d21fdc6948b0d6cff4c94cd89fa441197182c
CandidateCDHashFull sha256=3e5d21fdc6948b0d6cff4c94cd89fa441197182c72119f76a8407aa2c2ce2f0e
Hash choices=sha256
CMSDigest=3e5d21fdc6948b0d6cff4c94cd89fa441197182c72119f76a8407aa2c2ce2f0e
CMSDigestType=2
CDHash=3e5d21fdc6948b0d6cff4c94cd89fa441197182c
Signature size=8980
Authority=Developer ID Application: company name (<TEAM ID>)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=18 Aug 2021 at 5:26:47 pm
Info.plist entries=11
TeamIdentifier=<TEAM ID>
Runtime Version=10.15.0
Sealed Resources version=2 rules=13 files=413
Internal requirements count=1 size=188

The cdhash 3e5d21fdc6948b0d6cff4c94cd89fa441197182c is present in the developer log of notarization twice:

    {
      "path": "my_app.zip/my app.app/Contents/MacOS/my app",
      "digestAlgorithm": "SHA-256",
      "cdhash": "3e5d21fdc6948b0d6cff4c94cd89fa441197182c",
      "arch": "x86_64"
    },
        {
      "path": "my_app.zip/my app.app",
      "digestAlgorithm": "SHA-256",
      "cdhash": "3e5d21fdc6948b0d6cff4c94cd89fa441197182c",
      "arch": "x86_64"
    }

When I run the spctl /usr/sbin/spctl --assess --type exec -vv "/Path/to/my app.app"

I get

/Path/to/my app.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: company name (<TEAM ID>)

My codesign was run using Avalonia's bash script with added --deep

#!/bin/bash
APP_NAME="/Path/to/my app.app"
ENTITLEMENTS="/Path/to/entitlements/my_app.entitlements"
SIGNING_IDENTITY="Developer ID Application: company name (<TEAM ID>)"

find "$APP_NAME/Contents/MacOS/"|while read fname; do
    if [[ -f $fname ]]; then
        echo "[INFO] Signing $fname"
        codesign --deep --force --timestamp --options=runtime --entitlements "$ENTITLEMENTS" --sign "$SIGNING_IDENTITY" "$fname"
    fi
done

echo "[INFO] Signing app file"

codesign --deep --force --timestamp --options=runtime --entitlements "$ENTITLEMENTS" --sign "$SIGNING_IDENTITY" "$APP_NAME"

After notarization I receive an e-mail from Apple that my software was 'successfully notarized'.

However, when I run xcrun stapler staple "/Path/to/my app.app" I get

Processing: /Path/to/my app.app
Could not validate ticket for /Path/to/my app.app
The staple and validate action failed! Error 65.

If I run stapler with -v I can see that the ticket is successfully downloaded.

Boost

Answer 1

DTS Engineer OP

Apple

Aug ’21

With regards your stapling error, you wrote:

If I run stapler with -v I can see that the ticket is successfully downloaded.

Can you post this verbose log?

Also, your code signing seems more than a little wonky. To do a full analysis I’d have to look at a copy of your app but there are some serious warning signs. You wrote:

I followed the guide here …

That doc start with this diagram:

MyProgram.app
|
----Contents\
    |
    ------_CodeSignature\ (stores code signing information)
    |     |
    |     ------CodeResources
    |
    ------MacOS\ (all your DLL files, etc. -- the output of `dotnet publish`)
    |     |
    |     ---MyProgram
    |     |
    |     ---MyProgram.dll
    |     |
    |     ---Avalonia.dll
    …

This is wrong, although the exact brokenness depends on the nature of MyProgram.dll and Avalonia.dll:

If these files are Mach-O images, they should be in Contents/Frameworks.
If not, and this is my expectation here, they should be in Contents/Resources.

The Contents/MacOS directory is reserved for helper tools and apps, and a .dll file is definitely not that. See the Nested Code section of Technote 2206 macOS Code Signing In Depth for the details.

My codesign was run using Avalonia's bash script with added --deep

Signing with --deep is almost always a mistake. See --deep Considered Harmful for an explanation as to why. In this case you’re applying entitlements to library code. At best that’s benign; at worst, it can prevent your program from launching.

For concrete advice on how to sign and package Mac products, see Signing a Mac Product For Distribution.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1