HOWTO macOS notarization (plugins, app, pkg installers)

[newsonicarts]

I couldn't get that to work exactly, but I noticed the stapler command itself doesn't actually need the UUID, so I figured out a simpler way to do it. Instead of polling the UUID in the loop, just re-try stapling until it succeeds. Seems to work here.

If anyone is interested...

Code: Select all

xcrun altool --notarize-app --primary-bundle-id "$BUNDLEID" --username "$USERNAME" --password "$PASSWORD" --file "$FILE"

while true; do
printf "(Attempting stapler in 30...)\n"
sleep 30
if xcrun stapler staple "$FILE" | grep -q "The staple and validate action worked!";
then
break
fi
done

[daniel_noiseash]

Hi

Apple app-specific password usage is limited to 25 max.
Can we use same the app-specific password for multiple plugins?
Or do we have to use unique app-specific passwords for each plugin individually?

[Markus Krause]

You can use the same one for several products

[newsonicarts]

Does anyone know if you can disable the notification email?
Its kinda annoying when everything is setup and working (and you have confirmation from your script anyway)

[newsonicarts]

Recently the notarization script fails often because 'timestamp cannot be obtained from server'. More annoying time wasting as the build process is so slow, especially now with UB.

I'm not 100% sure but this seems to happen when the computer screen goes blank due to no input (which usually happens on these long builds), seems like some kind of semi-sleep mode is enabled but the build is still going in the background.. but the network doesnt work, maybe.. just a hunch.

Is anyone else experiencing this, and/or any known solutions?

[mystran]

I'm not 100% sure but this seems to happen when the computer screen goes blank due to no input (which usually happens on these long builds), seems like some kind of semi-sleep mode is enabled but the build is still going in the background.. but the network doesnt work, maybe.. just a hunch.

You could easily test if it's a display sleep issue I think. System Preferences -> Battery (at least on laptops; not sure if it's called the same on a system with no battery) -> select either Battery or Power Adapter -> drag "when display goes to sleep" all the way to the right (never).

That said, I wonder if it might also be somehow related to AppNap which seems like super-aggressive in some macOS versions. Not sure if it was Big Sur or earlier, but I had some trouble with a game project of mine where when running a local server for the client in a background thread, sometimes the server thread would get suspended (ie. not scheduled at all for a while) especially if the client wasn't visible on screen and I suspect it was an AppNap issue as beginActivity: with NSActivityUserInitiatedAllowingIdleSystemSleep seems to have solved the issue.

So perhaps it's something like the notarization process getting suspended by AppNap when it's "hidden from view" because the display sleeps?

[george]

I'm not 100% sure but this seems to happen when the computer screen goes blank due to no input (which usually happens on these long builds), seems like some kind of semi-sleep mode is enabled but the build is still going in the background.. but the network doesnt work, maybe.. just a hunch.

Have you tried using caffeinate command? It may solve sleeping issues.

https://ss64.com/osx/caffeinate.html

[newsonicarts]

Thanks, thats helpful, I was hoping for a scriptable solution like that

[Markus Krause]

some questions about .pkg Installers, Rosetta and SHA256 hashes

1) I am using a M1 Mac with Big Sur to build and codesign universal binaries (Intel+ARM).

2) Then I copy the .component and the .vst to my Intel Mac with Mac 10.14. Here I build the .pkg installer with Packages and run the Notarisation. I am using the old Mac to keep downward compatibility with older MacOS versions, as the certificates on BigSur are SHA256 only.
Big Sur does not correctly sign pkg files using SHA1 which is required by El Capitan (10.11) and earlier (planed obscolescense?). Sierra (10.12) and later seem to correctly pickup the SHA256 signature.
Reference: https://developer.apple.com/forums/thread/664842

3) One customer reported that he was not able to run my .pkg installer, as it would 'just run under Rosetta' and he had uninstalled Rosetta on his system.

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

Question1:
How do you handle the SHA1 issue with your installers?

Question2:
I am confused about the 'Rosetta issue' that the customer reported. Is the customer telling missinformation? If not what does happen with our old installers when Apple should drop Rosetta, especially those for soundsets. Does Rosetta affect .pkg installers at all?

Question3:
How do the .pkg installers work from the technical side. I thougth it would just be some kind of script that decompresses and copys files

[audiothing]

Check my previous post regarding signatures:

Big Sur 11.3 fixed the missing SHA1 signature for both codesign and productsign. We have moved our dev machine to Big Sur and can confirm everything works as it should (from 10.9 to 11.3.1).
If you are using Packages for your installers you might need to re-sign them using productsign directly to make sure the right signatures are applied.

I would just migrate to pkgbuild directly to be honest.

Regarding Rosetta, you need to put this flag to tell the installer architectures:
hostArchtectures="x86_64,arm64"
In packages you need to select Show Advanced User Options.

[Markus Krause]

Regarding Rosetta, you need to put this flag to tell the installer architectures:
hostArchitectures="x86_64,arm64"
In packages you need to select Show Advanced User Options.

Thanks a lot for this!

[george]

Regarding Rosetta, you need to put this flag to tell the installer architectures:
hostArchtectures="x86_64,arm64"
In packages you need to select Show Advanced User Options.

Exactly.

[Markus Krause]

"x86_64,arm64" separated with a comma or a space?

[george]

hostArchitectures="x86_64,arm64" is probably referring to pkgbuild syntax.

In Packages it works using arm64 x86_64 with a space.

[Markus Krause]

After September 2023 the notarisation that we currently use will not longer work and we will be forced to migrate to XCode 13 or higher:
https://developer.apple.com/videos/play/wwdc2022/10109/
https://developer.apple.com/videos/play/wwdc2021/10261