SD Notary 1.0.1 Released

Announcements
,
#1

Originally published at: https://latenightsw.com/sd-notary-1-0-1-released/

We are pleased to announce the release of SD Notary 1.0.1. SD Notary is a tool for notarizing AppleScript and Automator apps.

1 Like
#2

Hi. And again thank you, Shane and Mark, for SD Notary.
However I got stuck with an error: “Unknown problem using altool.”
When trying to notarize an applet, SD Notary approves the signing identity and all filled in fields, but still gets an unknown error
08:22:46.487: Checking if Apple ID, key for app-specific password in login keychain, and team provider are in sync...
08:22:48.610: Unknown problem using altool.
The only special thing with my setup is that I have created the app specific password with one Apple ID (used as developer ID) and added it to my login keychain on a computer that is connected to iCloud with another Apple ID (my private) – as discussed in Mojave 10.14.5 and Notarization

#3

I don’t think iCloud comes into it. Check that the Apple ID you are using in SD notary matches that used to set up the app-specific password, and that the password in your keychain also uses the same password.

#4

It does, absolutely. The account name (email adress) filled in for “Apple ID” in SD notary is identical to the account name in “Account” in the keychain item. And the password for the latter is the app specific password made for that Apple ID. (When at first I filled in the keychain item wrongly, I got other more descriptive error messages).

#5

When hitting the “Fetch history” button, I get the message below. Can I interpret it as a temporary “general error” at the other end?

Fetching notarizing history...
09:19:31.558: Problem using altool.
Error message: 2019-05-17 09:19:31.450 altool[27280:1224765] *** Error: Failed to get notarization history:
(
    "Error Domain=ITunesConnectionOperationErrorDomain Code=1511 \"Unable to process developerIDPlusHistoryWithArguments request at this time due to a general error\" UserInfo={NSLocalizedRecoverySuggestion=Unable to process developerIDPlusHistoryWithArguments request at this time due to a general error, NSLocalizedDescription=Unable to process developerIDPlusHistoryWithArguments request at this time due to a general error, NSLocalizedFailureReason=Apple Services operation failed.}"
)```
#6

No. I’ve seen that message when deliberately entering wrong details. It’s probably the same problem you mentioned earlier.

#7

And try going to Xcode Preferences -> Locations, and check the right version of Command Line Tools is selected.

#8

Okay. So it seems I must use the same Apple ID as developer as I use for connecting my devices to iCloud to be able to notarize.
Before changing that, and updating my MacOS to 10.4.5 (still on 10.4.4), I wish to be sure it’s really necessary.
All my applets is made for in-house use only at my company. They are distributed to the users by Munki and by a self made solution (an applet that copies other applets from a file server when new or updated).
I code sign all these distributed applets for the main purpose that the users just have to allow Automation authorization for those apps once and for all.
So, just to be sure: After upgrading to 10.4.5 I will not be able to sign my applets at all – unless notarizing them? Meaning that after distribution, the users will have to hit the “Allow” button in those dialogs every time they run any of those (many) applets, not just the first time?

#9

The problem was the “Team provider short name” field (which SD notary demanded me to fill in even though I only belong to one team). I had entered what logically could be the short name for our team. Entering the full name for the team (consisting in several words) returned a descriptive error message, but not this “short name” so I didn’t think more about it.
Now I entered the developer team ID instead – and notarization works!
So my suggestion is to change the descriptive label of the field to “Team ID”
Thanks for the help along the way.

#10

Thanks for the update.

It fails on signing some included dylib files I use for communication with Postgres. I unchecked “Don’t sign enclosures”. Would I need to sign those binaries manually, or is there an option in SD Notary?

{
  "severity": "error",
  "code": null,
  "path": "path/to/lib/libssl.1.0.0.dylib",
  "message": "The signature of the binary is invalid.",
  "docUrl": null,
  "architecture": "x86_64"
}
#11

The next version will sign them. Until then, they will have to be done manually.

1 Like
#12

Have not tried it, but could it also be used to notarize apps/. Ideally you would be able to point to entitlements.
Right now I have a brute force bash script, but it is not very automated. I would love to hand off the process to another developer who is less week versed.
This would save me hours of debugging to set up.

#13

Yes. AppleScript applets are just standard, if basic, Cocoa apps. But it is being used for other apps (such as itself).

SD Notary lets you set all the hardened runtime entitlements.

#14

So it should work with an app set up. Actually, by the time it gets to notarization, it is is already signed deep (lots of components and frameworks.)

#15

You can let it do it again (it uses --force) or you can use the applescript interface to specifiy which subpaths to ignore.