Terminal can't find notarytool

General JUCE discussion
1

I have installed Xcode 16.2 on Sonoma 14.7.3. When trying to notarize in terminal I receive the error message: xcrun: error: unable to find utility “notarytool–notarize-app”, not a developer tool or in path

I notarized on my Macbook Air before moving to a new iMac. I had no problem doing it on the laptop.

Here’s the complete error messages:
xcrun: error: sh -c ‘/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -find notarytool–notarize-app 2> /dev/null’ failed with exit code 17664: (null) (errno=Invalid argument)

xcrun: error: unable to find utility “notarytool–notarize-app”, not a developer tool or in PATH

Any solutions?

2

I think we’ve been through this before in the other codesigning thread. It’s not called notarytool–notarize-app but notarytool. The --notarize-app part was an argument that was passed to the old altool, which you’re no longer supposed to use. notarytool doesn’t need the --notarize-app argument (and even if it did, there would be a space between notarytool and --notarize-app).

1 Like
3

Sorry, my bad… :} I was copying and pasting from previous notarizations. Thanks for helping me! Now let’s try again…

5

OK, may bad again. Copied yet another faulty code line. I think I found the correct one now. It seems to work.

6

I’m having the same problems you helped me with last time when I did this on the MacBook. Just like then my submission is accepted but I receive status: invalid. I download the log, which tells me: “The binary is not signed with a valid Developer ID certificate.” and “The signature does not include a secure timestamp.”. These are the same error messages as last time. You suggested that I may have had the wrong plugin zipped and I zipped it again, and this time the submission was accepted.

I have zipped the file again and the submission is still invalid with the same logged errors. I have tried to sign the file again, but get the message that the file is already signed. When I first tried to sign this new instrument version of the plugin, I received the message that it was already signed. Still I had a new bundle number, new product name, new plugin code and it was built from a new JUCE project. The difference between the old and the new alternative plugin was that the new one is in instrument format. Can the signing procedure still see the new plugin as being the old one and not wanting to sign it again? Then when trying to notarize I receive error message that the file isn’t signed.

7

When you do codesign -dv --verbose=4 /path/to/your/VST, what does it print out?

What is the full command that you’re using to do the codesigning? Please put it between ``` three ticks so that the forum doesn’t mangle the actual command.

Likewise, what is the full command you’re using for the notarization?

8 

Executable=/Users/Hans/Library/Audio/Plug-Ins/VST3/Art Vista Intonator i.vst3/Contents/MacOS/Art Vista Intonator i

Identifier=com.ArtVistaProductions.ArtVistaIntonatori

Format=bundle with Mach-O universal (x86_64 arm64)

CodeDirectory v=20400 size=57987 flags=0x2(adhoc) hashes=1803+5 location=embedded

VersionPlatform=1

VersionMin=658688

VersionSDK=983552

Hash type=sha256 size=32

CandidateCDHash sha256=612482d210eb4c6096bc12e759be60a02fd453e3

CandidateCDHashFull sha256=612482d210eb4c6096bc12e759be60a02fd453e3492025fa18c617619d489b48

Hash choices=sha256

CMSDigest=612482d210eb4c6096bc12e759be60a02fd453e3492025fa18c617619d489b48

CMSDigestType=2

Executable Segment base=0

Executable Segment limit=6057984

Executable Segment flags=0x0

Page size=4096

CDHash=612482d210eb4c6096bc12e759be60a02fd453e3

Signature=adhoc

Info.plist entries=20

TeamIdentifier=not set

Sealed Resources version=2 rules=13 files=2

Internal requirements count=0 size=12```
9

Hans@news-iMac ~ % codesign -s "Developer ID Application: Hans Adamson (ABCDE12345)" "/Users/Hans/Library/Audio/Plug-Ins/VST3/Art Vista Intonator i.vst3" --timestamp

Hans@news-iMac ~ % xcrun notarytool submit --apple-id "myemail@mydomain" --password "abcd-efgh-ijkl-mnop" --team-id "ABCDE12345" --wait /Users/Hans/Library/Audio/Plug-Ins/VST3/Art\ Vista\ Intonator\ i.vst3.zip

I wonder if these problems can have something to do with me creating this project by copying the original JUCE project folder, giving it a new name and changing the new project’s build parameters in JUCE. The bundle name and plugin code and the plugin name are new.

10

Note how it says Signature: adhoc. That means it’s not signed with your Developer ID certificate.

11

OK, Apple recommended to verify the signing with this:
codesign -vvv --deep --strict "/Users/Hans/Library/Audio/Plug-Ins/VST3/Art Vista Intonator i.vst3"
which I did, but evidently the binary still isn’t signed. Every time I try to sign, I get the message that it is already signed.

When doing the verification above I received:
/Users/Hans/Library/Audio/Plug-Ins/VST3/Art Vista Intonator i.vst3: valid on disk
/Users/Hans/Library/Audio/Plug-Ins/VST3/Art Vista Intonator i.vst3: satisfies its Designated Requirement

Can an adhoc signature be replaced with a proper signature? Or maybe if I delete the binary, make some changes to the new JUCE project and build a new plugin. Can I avoid the adhoc signature?

What if I use this to sign with my developer ID:
codesign --force --timestamp --verbose --sign <sign-id> <file>
https://forum.juce.com/t/solved-plugins-automatically-signed-incorrectly-during-build-on-macos/52690

Would this be the way to do it?
codesign -s --force —verbose "Developer ID Application: Hans Adamson (ABCDE12345)” "/Users/Hans/Library/Audio/Plug-Ins/VST3/Art Vista Intonator i.vst3" --timestamp

But the question is why it was signed with adhoc in the first place…

12

If you don’t set up codesigning in Xcode or in Projucer, then it’s signed with an adhoc certificate so you can run and debug the program on your own computer.

You can indeed re-sign the VST afterwards with your own signature, using the command you’ve shown. That’s how I do it.

1 Like
13

Always prefix these tools with “xcrun”, you’ll thank me later.

(xcrun is your friend: Multiple Xcode versions or Why xcrun is your friend | by Artem Loenko | Medium)

Oh, and also: don’t be doing codesigning/notarization in any environment that isn’t a VM that you can back up and save for later.

1 Like
14

Now I am getting this:
xcrun codesign -s --force —verbose "Developer ID Application: Hans Adamson (ABCDE12345)" "/Users/Hans/Library/Audio/Plug-Ins/VST3/Art Vista Intonator i.vst3" --timestamp

error: The specified item could not be found in the keychain.

I checked and my certificate Developer ID Application is in the keychain. OK, so I click on the certificate and in red letters a message that this “certficate is not trusted”. At the same time when I check the certificate on my MacBook, the message is green saying: “This certificate is valid” What’s wrong?

Screenshot 2025-02-26 at 8.55.17 AM
Screenshot 2025-02-26 at 8.55.17 AM265×309 19.3 KB

How to start with signing audio plugins?
15

Those arguments that you’re passing to codesign cannot appear in any random order. The -s and the "Developer ID Application: Hans Adamson (ABCDE12345) parts go together.

xcrun codesign --force --verbose -s "Developer ID Application: Hans Adamson (ABCDE12345)" "/Users/Hans/Library/Audio/Plug-Ins/VST3/Art Vista Intonator i.vst3" --timestamp

1 Like
16

Thanks, appreciate it. now I need to figure out why my developer certificate is not trusted on this new Mac while it is valid on the MacBook…?

17

A certificate consists of two parts: the certificate itself (public) and a private key (private). Did you download the private key from the MacBook and import it into Keychain Access on the new Mac?

1 Like
18

I think I just installed it by the same process as when I installed it on the MacBook. But I have exported from the MacBook now and will try and transfer it to the new Mac. What I can see is a “certificate” in the keychain. When I right-click on it I can export it. So I will put it on the new Mac!

Thanks!

19

why this?

20

this makes no sense

21

why this?

Do you want the codesigning certificate and keys to your million-dollar application (hopefully with IAP’s) floating around on a laptop that you can easily lose/misplace forever?

The codesign’ing/notarization phase of distribution means you’re entered into a pact with Apple/PACE (if you are signing AAX bundles too) and so on … the passwords and keys which control that pact should be placed in a VM with the sole purpose of doing that codesign’ing/notarizing, and backed up like you would any other cert worth (potentially) a lot of money.

Developer laptops are the worst place to have the signing keys and passwords. Always distinguish between development and distribution - especially if you are going to have tens of thousands of customers - by using a build server designed specifically to be separate from the development machine.

Too many times I’ve seen companies fail to do updates to their software because the signing keys were lost and they have to change bundle ID’s, leaving their customers to wonder where all the updates went …