KVR Audio

george · Post by **george** » Thu Jun 09, 2022 3:30 pm

Markus Krause wrote: Thu Jun 09, 2022 3:00 pm After September 2023 the notarisation that we currently use will not longer work and we will be forced to migrate to XCode 14:
https://developer.apple.com/videos/play/wwdc2022/10109/
https://developer.apple.com/videos/play/wwdc2021/10261

Very interesting Markus. Will check ASAP.

Markus Krause · Post by **Markus Krause** » Thu Jun 09, 2022 4:14 pm

I checked it out. It seems that Notarytool is also already available in Xcode13:
https://developer.apple.com/documentati ... n_workflow

XCode 13.2 is the last one that still runs with BigSur.
XCode 12.4 (without Notarytool) was the last version that still runs with Catalina. In practice building for ARM will not longer be possible with Intel machines. I assume that signing with SHA1 will also not longer be possible, which means that the minimum system requirement will be MacOS10.11 and we're forced to drop support below that.
Those developers who still did not buy an ARM mac need to buy one before September 2023.

BigSur or higher is required to run Notarytool.

You can avoid Xcode dependency by using the notary service REST API described here:
https://developer.apple.com/documentati ... er_the_web

audiothing · Post by **audiothing** » Thu Jun 09, 2022 5:02 pm

Markus Krause wrote: Thu Jun 09, 2022 4:14 pmSigning with SHA1 will also not longer be possible, which means that the minimum system requirement will be MacOS10.11 and we're forced to drop support below that.

Why? As of now, that's not true. As I replied to your previous post, again:

Big Sur 11.3 fixed the missing SHA1 signature for both codesign and productsign.

Are they going to change that back again? Hopefully not. Right now, we can easily support from 10.9+ using just Big Sur 11.3.

Anyway, notarytool seems an easy way to implement the notarization, if they really sped up the whole process, that's great. The real concern here is if they force us to use the newer Xcode version every time they update it, that would be a bad sign.

Lind0n · Post by **Lind0n** » Sun Jul 24, 2022 4:57 pm

Okay coming back here as I'm changing my distribution approach - from a WhiteBox packages solution to an in-house installer (which I have code signed - hardened run time) and notarized... and stapled.

But... my in-house installer "just" unzips each of the mac plugins(VST3 and AU) and puts them in the correct locations, so they ship as zipped up plugins only. Now I've code signed them AND notarized them, but anyone know if I need to staple them too?

Markus Krause · Post by **Markus Krause** » Tue Jul 26, 2022 9:50 am

I think you must also staple them. Otherwise the notarisation step would not make sense.

1) Code sign
2) Notarize
3) Staple

Urs · Post by **Urs** » Tue Jul 26, 2022 10:07 am

You need to staple installers in order to run on computers which are not connected to the internet.

Lind0n · Post by **Lind0n** » Tue Jul 26, 2022 6:36 pm

hmm, confused now -- not asking about installers, asking about plugins... do they need anything past code signing? - Sorry if I wasn't clear.

Urs · Post by **Urs** » Tue Jul 26, 2022 6:44 pm

Lind0n wrote: Tue Jul 26, 2022 6:36 pm hmm, confused now -- not asking about installers, asking about plugins... do they need anything past code signing? - Sorry if I wasn't clear.

Kind of.

When you notarize the installer (or a .dmg), you also notarize all executables in it. In order to get notarised, things need to be codesigned.

IDK if one can notarize just binaries.

Markus Krause · Post by **Markus Krause** » Wed Jul 27, 2022 2:24 pm

Urs wrote: Tue Jul 26, 2022 10:07 am You need to staple installers in order to run on computers which are not connected to the internet.

That's an interesting detail. This means that we could theoretically skip stapling for the demo-versions as the user usually downloads them and is connected to the web.

Lind0n · Post by **Lind0n** » Thu Jul 28, 2022 12:11 pm

Okay it seems Im not being clear... sorry again.

I have code signed all my plugins, I then zipped them up and sent them off to be notarized...all done.

Now I am wondering if I need to staple the plugins too, and if so what am I stapling. I have the original (codesigned) plugins sitting on my desktop, and two zip files that I sent off to Apple (which contain copies of these plugins), do I staple these original plugins? Do I unzip the zipped ones and staple them? Is there any difference here?

I guess (at best) I'm trying to get an understanding what each of these processes do, so let me start out by defining what I think is happening in each of these processes:

1. Codesigning...some small piece of certification is added into the binary to identify me as the developer
2. Notarization... well it seems Apples servers cant handle plugins for some reason so I have to zip up my plugins and send the zip file across. The Apple servers check over the contained code to make sure its not doing anything malicious and if so records that this binary from me is all OK, and then tells me its done that via email. So there's nothing changed about the codesigned binaries on my machine.
3. Stapling ... well at this point I'm a bit lost, I'm guessing (and it is a guess) the stapling process checks with the apple servers to make sure that this binary has passed notarization and again puts something in the binary to say so.
4. MacOS runs an app - it checks that its codesigned and then checks in with the Apple servers to make sure this is OK code...if its got no internet access then it checks the staple-added flag to make sure its all ok.
5. DAW runs a plugin - it checks that it is code signed, if so what then? Is it also checking notarization state, either by Apple server or staple flag?

Markus Krause · Post by **Markus Krause** » Thu Jul 28, 2022 1:03 pm

Not sure if it works with a zip but I'd try this:

To staple enter:
xcrun stapler staple yourFiles.zip

Then check if it works by entering:
spctl -a -vvv -t install "yourFiles.zip"

Lind0n · Post by **Lind0n** » Thu Jul 28, 2022 1:36 pm

Markus Krause wrote: Thu Jul 28, 2022 1:03 pm Not sure if it works with a zip but I'd try this:

To staple enter:
xcrun stapler staple yourFiles.zip

Then check if it works by entering:
spctl -a -vvv -t install "yourFiles.zip"

sure, but why would I staple a zip? it doesnt make any sense...

Lind0n · Post by **Lind0n** » Thu Jul 28, 2022 2:36 pm

Okay _ I spent some more time in the apple dev forums to get this (useful) information:

So, to clarify, Apple’s general recommendation is that you:
Sign all your code from the inside out, up to and including any signable containers.

Then notarise and staple the outermost container.

Ship that stapled container.

So, for example, if you ship an app inside an installer package on a disk image, you’d sign the app, then the installer package, then the disk image, and then notarise and staple the disk image.

The ticket that you staple to the outermost container will cover any nested containers and code. The system ingests this ticket when you open the outermost container for the first time.

There are exceptions to this rule. Most of them are edge cases that most folks can ignore, but there’s one important one. If you ship an app inside a zip archive, you can’t sign your outermost container because zip archives don’t support signing. In that case you should:
1. Sign the app.

2.Zip that.

3.Notarise that.

4.Take the app from step 1 and staple that.

5.Zip that.

6.Ship the zip archive from step 5.

The system will ingest this ticket when the user first launches the app.

So for zipped up stuff that needs delivering IN the zip then if zip stapling wont work.... follow steps 1-6 above...

Markus Krause · Post by **Markus Krause** » Thu Jul 28, 2022 2:54 pm

Uhh. This is a really ugly workflow.

And 7) Don't forget to check out if all this worked by entering:
spctl -a -vvv -t install "yourFiles.zip"

Markus Krause · Post by **Markus Krause** » Thu Jul 28, 2022 2:58 pm

Did you try this?

1. Sign App
2. Notarize App
3. Staple App
4. Zip App

HOWTO macOS notarization (plugins, app, pkg installers)