SD Notary of Automator Applications

Hi Shane & LNS. Firstly thank you VERY much for SD Notary. I use it often to greatly simplify the minefield of Apple notarization for the apps I am making

I have hit a problem however with a couple of Automator applications that I use. The screenshot above shows the very simple one step app that I use to Split PDFs within one of the tools. Even extracting from the tool I cannot seem to code sign it. So far I have tried:

  1. Exporting from Automator with an Developer ID Application attached.
  2. Saving as an app and running through SD Notary
  3. Saving as an app and running the line here before
  4. Placing inside an applet and signing that through SD Notary

I still a report back from Apple that mentions

  • The signature does not include a secure timestamp.
  • The executable does not have the hardened runtime enabled.
  • The signature of the binary is invalid.

I’m using SD Notary v1.4.3

Hope you can help, let me know if you need anything else from me

What version of macOS are you running?

The screenshot is from 10.14 but also have 10.15 and 11 (final beta). Getting same results in all.

Would it be possible for you to recreate the one step Automator app and codesign it successfully as a demonstration please?

Sure. You image looks like it was run on Big Sur, so I tried it there:

10:01:48.985: LogFileURL full contents: {
  "logFormatVersion": 1,
  "jobId": "e82c2612-f608-4ebc-9821-891fbc7f734a",
  "status": "Accepted",
  "statusSummary": "Ready for distribution",
  "statusCode": 0,
  "archiveFilename": "Split_PDF.zip",
  "uploadDate": "2020-11-11T22:59:52Z",
  "sha256": "d4cadddc7ad7fbead4153c2ae8da6be3ec1c2ce0aa2d247b1c3a14147dce732b",
  "ticketContents": [
    {
      "path": "Split_PDF.zip/Split_PDF.app/Contents/document.wflow",
      "digestAlgorithm": "SHA-256",
      "cdhash": "d1daa9d427f570171bb2f4e31916c964c2066d8a",
      "arch": null
    },
    {
      "path": "Split_PDF.zip/Split_PDF.app",
      "digestAlgorithm": "SHA-256",
      "cdhash": "9949b741497fb42c68aff4eee71018eb7d009d44",
      "arch": "x86_64"
    },
    {
      "path": "Split_PDF.zip/Split_PDF.app",
      "digestAlgorithm": "SHA-256",
      "cdhash": "200833f63e03799142f6e5693381595f510b3551",
      "arch": "arm64"
    },
    {
      "path": "Split_PDF.zip/Split_PDF.app/Contents/MacOS/Automator Application Stub",
      "digestAlgorithm": "SHA-256",
      "cdhash": "9949b741497fb42c68aff4eee71018eb7d009d44",
      "arch": "x86_64"
    },
    {
      "path": "Split_PDF.zip/Split_PDF.app/Contents/MacOS/Automator Application Stub",
      "digestAlgorithm": "SHA-256",
      "cdhash": "200833f63e03799142f6e5693381595f510b3551",
      "arch": "arm64"
    }
  ],
  "issues": null
}

I also tried putting that applet (unsigned) into the Resources folder of a new applet, and that got notarized fine also.

That’s good news!
Some more info please

Did you save or export from Automator?
If expecting did you codesign in Automator?

When running though SD Notary
Did you change the default settings?
Did you need an app specific password?
Did you press the ‘Sign Only?’ button or otherwise

I’ve become accustomed to using sign only in SD Notary and then apply hardened run time to the wrapper app in Xcode.

Thanks for your help

Saved as an app.

No – no point.

They’re irrelevant to whether it succeeds or not.

Yes.

No.

It’s much better to do the whole thing in SD Notary.

Thanks Shane

I have never submitted using SD Notary as I bundle several dozen apps into each main Xcode product app and then use that to sign and apply hardened runtime when building. I then package into a DMG and notarise that through altool

This works well for all my Script Editor apps.

Just not able to do this for the couple of Automator apps I use.

When trying to submit the Automator apps through SD Notary I get:

Package Summary:

1 package(s) were not uploaded because they had problems:
/var/folders/6z/qq359z7s0jlf_0xb5p3k1wj80000gn/T/4CCEDA1B-4C54-43A8-A216-5375350909C9/Untitled.itmsp - Error Messages:
Your Apple ID account is attached to other providers. You will need to specify which provider you intend to submit content to. Please contact us if you have questions or need help. (1627)

You’re doing it the hard way. Add the apps to your Xcode app, make a release build (Build For Profiling), then use SD Notary to sign that. Everything in the bundle will be signed recursively. Then you can make the .dmg and submit that.

That means you need to supply a Provider short name. Click the Choose… button and select the appropriate one.

I am not surprised I am doing it the hard way. It does seem hard but at least it is a way that is working! I add other things to the DMG, so doesn’t the DMG then also then need to be notorized?

I see this when trying to choose a provider short name via the choose button

The .dmg needs to be notarized. But you can Sign only… the app you add to the .dmg.

It looks like the earlier error message was misleading. Have you set up an app-specific password for altool?

Yes, I am using app-specific passwords when using SD Notary to successfully ‘Sign Only…’ my Script Editor made applications and the same app-specific password when using altool though terminal on the final DMG.

Do I need a different app specific password for Automator made applications?

You use the same app-specific password.

The app-specific password is not used in that case – it’s only used for notarizing.

I’m not sure I can add much more. If you want to let Xcode do the signing of your main bundle, and to use Terminal for altool, you might as well just use codesign in Terminal to sign the Automator actions, and skip SD Notary altogether.

I have not, as yet, ever used codesign in Terminal. This is what I like SD Notary so much. I haven’t had to work out how to do that!

So as it stands I am left unable to sign the Automator made apps using SD Notary in the same way I use SD Notary successfully to sign Script Editor made apps.

I’m not sure how you can successfully code sign your ‘Application Stub’ and I cannot.

“issues”: [
{
“severity”: “error”,
“code”: null,
“path”: “CircularFLO_2020.0.36.dmg/CircularFLO.app/Contents/Resources/Split_PDF.app/Contents/MacOS/Application Stub”,
“message”: “The signature of the binary is invalid.”,
“docUrl”: null,
“architecture”: “x86_64”
},
{
“severity”: “error”,
“code”: null,
“path”: “CircularFLO_2020.0.36.dmg/CircularFLO.app/Contents/Resources/Split_PDF.app/Contents/MacOS/Application Stub”,
“message”: “The executable does not have the hardened runtime enabled.”,
“docUrl”: null,
“architecture”: “x86_64”
}
]

Can you suggest a reason? or if I need to figure how to codesign in Terminal the best resource for that info please?

Thanks again for your time and expertise. Really appreciate it.

Send me your file to look at.

Emailed a link to your latenightsw email.

Thank you

The file is being signed fine. The problem is happening when Xcode tries to sign the full app that contains it. If you let SD Notary sign the completed app rather than Xcode, as I outlined above, the problem should go away.

Turn off the hardened runtime in Xcode and just use ad-hoc or signed to run locally. Then use SD Notary to do the signing.

(I suspect Xcode is trying to override the Automator app’s signature. But Automator apps need special treatment because their bundle layout breaches Apple’s recommendations, and Xcode doesn’t understand how to do it.)

Thanks for the info.

I am unable to do that currently as I get a “Your Apple ID account is attached to other providers. You will need to specify which provider you intend to submit content to. Please contact us if you have questions or need help.”

Which is untrue (the Apple ID is NOT attached to other providers) and I read on the Apple Dev forums that this may be a bug. This is not a SD Notary problem and so I will attempt to pick that up with Apple.

As and when I have that solved… I will try again to use SD Notary to do the signing and confirm back here if I have success!

Thanks again for your advice on this.

FWIW, there’s another tool that can do what SD Notary does, with more options, including the ability to add the “hardened runtime” setting to existing code. It also manages your signing certs better and remembers your settings per app.

It’s not free but I found it worth its money:

I believe version 4 is currently in beta and free to try. Why don’t you have a go at it and report back if that helps?

The developer is also very approachable and currently open to any suggestions while working on the new version.