notarize existing color picker fails

Question

I'm trying to notarize an existing color picker pane. Color picker panes (additions to the system colorpicker) are bundles with a .colorPicker extension and a structure similar to a .app bundle.

1.) I signed the colorPicker bundle with:

codesign -f -s "Developer ID Application: MyCompany, LLC " /Users/ralph/MyColorPicker.colorPicker --timestamp --deep --options runtime

note the --timestamp

2.) I then used DropDMG to wrap the .colorPicker bundle in a dmg and then signed the dmg

codesign -f -s "Developer ID Application: MyCompany, LLC " /Users/ralph/MyColorPicker.colorPicker.dmg --timestamp --deep --options runtime

3.) I then submitted the dmg to the notarization service with:

xcrun altool --notarize-app -f /Users/ralph/MyColorPicker.colorPicker.dmg

--primary-bundle-id com.mycompany.MyColorPicker -u AppleID -p AppSpecificPassword

It loaded without error, but then the dread email...

Your Mac software was not notarized

After going throughthe conniptions to get the ridiculously long URL for the log file, this is what it thinks is wrong

{

"severity": "error",

"code": null,

"path": "MyColorPicker.colorPicker.dmg/MyColorPicker.colorPicker/Contents/Resources/EWSMacCompress.tar.gz/EWSMacCompress.tar/EWSMac.framework/Versions/A/EWSMac67108868",

"message": "The binary is not signed.",

"docUrl": null,

"architecture": "x86_64h"

},

{

"severity": "error",

"code": null,

"path": "MyColorPicker.colorPicker.dmg/MyColorPicker.colorPicker/Contents/Resources/EWSMacCompress.tar.gz/EWSMacCompress.tar/EWSMac.framework/Versions/A/EWSMac67108868",

"message": "The signature does not include a secure timestamp.",

"docUrl": null,

"architecture": "x86_64h"

}

??? I thought I signed it and with the --timestamp option.

Investigating:

codesign -vvv --deep --strict /Users/ralph/MyColorPicker.colorPicker.dmg

results in:

/Users/ralph/MyColorPicker.colorPicker.dmg: valid on disk

/Users/ralph/MyColorPicker.colorPicker.dmg: satisfies its Designated Requirement

codesign -dvv /Users/ralph/MyColorPicker.colorPicker.dmg

results in:

Identifier=MyColorPicker.colorPicker

Format=disk image

CodeDirectory v=20200 size=319 flags=0x10000(runtime) hashes=1+6 location=embedded

Signature size=8939

Authority=Developer ID Application: MyCompany, LLC (XXXXXXXXXX)

Authority=Developer ID Certification Authority

Authority=Apple Root CA

Timestamp=Apr 16, 2020 at 10:06:14 AM

Info.plist=not bound

TeamIdentifier=XXXXXXXXXX

Sealed Resources=none

Internal requirements count=1 size=192

--------------------------------

Any insights greatly appreciated. This is driving me nuts.

324

Posted by

slweiss

Reply

Add a Comment

Answer 1

The main issue here is that you’re relying on

--deep

. This is a mistake, as I outlined in

--deep

Considered Harmful. Rather, you should sign each code item separately, from the inside out, as described in Signing a Mac Product For Distribution.

Beyond that, something weird is going on with your colour picker’s structure. Consider the path that the notary service is complaining about:

MyColorPicker.colorPicker.dmg/
  MyColorPicker.colorPicker/
    Contents/
      Resources/
        EWSMacCompress.tar.gz/
          EWSMacCompress.tar/
            EWSMac.framework/
              Versions/
                A/
                  EWSMac67108868

Your product contains a tar archive that itself contains native code. This is quite strange, and it’s going to make notarisation trickier. You will have to unpack that tar archive, sign the framework, and then repack the tar archive.

Alternatively, you could restructure your product to avoid this weirdness. A colour picker is just a bundle, and you can place frameworks inside its

Contents/Frameworks/

directory just like you’d do for any other bundle.

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

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

Posted by

eskimo

Add a Comment

Answer 2

The main issue here is that you’re relying on

--deep

. This is a mistake, as I outlined in

--deep

Considered Harmful. Rather, you should sign each code item separately, from the inside out, as described in Signing a Mac Product For Distribution.

Beyond that, something weird is going on with your colour picker’s structure. Consider the path that the notary service is complaining about:

MyColorPicker.colorPicker.dmg/
  MyColorPicker.colorPicker/
    Contents/
      Resources/
        EWSMacCompress.tar.gz/
          EWSMacCompress.tar/
            EWSMac.framework/
              Versions/
                A/
                  EWSMac67108868

Your product contains a tar archive that itself contains native code. This is quite strange, and it’s going to make notarisation trickier. You will have to unpack that tar archive, sign the framework, and then repack the tar archive.

Alternatively, you could restructure your product to avoid this weirdness. A colour picker is just a bundle, and you can place frameworks inside its

Contents/Frameworks/

directory just like you’d do for any other bundle.

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

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

Posted by

eskimo

Add a Comment

Answer 3

Thanks for the heads up about --deep. This is my first experience with notarization and I was just copying the codesign comand from stuff on the web.

I agree that having xxxxx.tar.gz in the Resource directory is a bizarre way to structure things. My only excuse is I didn't do it. Upon investigation it is some automatically added junk leftover from an install of the (now defunct) Esellerate licensing software. I never noticed it before because in almost 10 years I have had no reason to look in that directory.

I was hoping to get away with notarizing what is there without redoing anything butI guess no such luck. Thanks again for your help!

Posted by

slweiss

Add a Comment

notarize existing color picker fails

Accepted Reply

Replies