I’m not out of the woods yet it seems. Although my installer passes notarisation, users are still getting hit with:
When I check the package use spctl I get:
rwalsh@Rorys-Mac-mini Installer % spctl -a -vv -t install installer.pkg
installer.pkg: accepted
source=Notarized Developer ID
origin=Developer ID Installer: R Walsh (NNNNNNNNNN)
I was under the impression that once that happened users would no longer see that warning? Most end-users know they can get around this by right-clicking and selecting open on the package, but it’s still kind of annoying. I thought that was the whole purpose of notarisation?
Thanks for this @baconpaul That’s next level scripting there! I’ve had a look down through it and I seem to be following more or less the same steps when it comes to the signing and notarising. Apple says my package is notarised, yet users still get that error message when trying to install it. If I can’t find the solution to this soon I guess I will have no choice but to contact Apple about it.
Are you using the latest version of Big Sur? I remember that there was a bug with code signing that didn’t work on older OS X versions when signed there. Updating macOS have fixed the problem.
yeah, the issue I’m having is that all signing and notarising is working. Yet users still get the untrusted message. I’ve been quite vocal about my disdain for Apple in the past, this is probably pay-pack
I think kunz meant big sur used a different hash on release, so it will not show the signing as correct on old OSs. Link in that forum thread: https://developer.apple.com/forums/thread/664842
But that’s been fixed now, apparently. I’ve been told you need at least Big Sur 11.3 and Xcode 12.5 to sign stuff that’ll be backward compatible.
hey @rory!
fwiw, we use Packages here (letting it do the signing internally) and use xcrun command to notarize, without issues. (and has there ever been a developer who has NOT had disdain for Apple signing!??!)
Thanks Matt! Anyhow, all good now. Using the exact same procedure on a different machine resolved the problem. No more annoying notifications about untrusted sources!
OT: I get the rationale behind this, but be careful: this way, you’re rewriting your GitVersion.h every time you build.
This will trick the build system into thinking that every file that includes that header needs to be rebuilt, even if in fact the version number hasn’t changed.
If I were you, I’d go the extra mile and make sure that GitVersion.h gets updated only when the version number actually changes, that may save you quite a lot of build time.
For example, you could echo all the things to a temp file, compare the temp file with the current content of GitVersion.h and, only if found different, overwrite GitVersion.h with the temp file.
If the temp file already had the same content of GitVersion.h, leave GitVersion.h alone so that its modification date remains in the past.
Thanks @asimilon, I double checked that I put them in the folder specified in the 3rd argument, still no luck. Am I right to think that this script should make these files appear during the installation process to begin with?
Also, would you happen to know how to modify distribution.xml to make it put my factory presets (xml files) into library/audio/presets/ folder by any chance?
I don’t think I’ve ever used the <readme> part, but the <license> file will show up and ask you to click agree before the installer gets going properly.
To do that you just need to create another package and add it to the distribution.xml, I usually make it something that can’t be switched off. I can’t go digging through my installers right at this moment to find details, if I remember later when have some spare time I’ll post again here with some more info if you don’t manage to figure it out yourself, but the gist of it is you need to use pkgbuild to create another installer package that puts your preset files in the right place, and then update the distribution.xml to add similar entries to ${VST3_PKG_REF}, ${VST3_CHOICE} and ${VST3_CHOICE_DEF}.
Thanks for that! So I am trying to do the needed modifications on my script. Been doing some trial and error stuff and now I am always blocked by this message. Is it possible that Apple is putting me on hold for abusing their bandwidth if I am constantly running make_installer to test my script?
Do you think developers new to JUCE would benefit from an easy-to-use, drag and drop interface for code-signing? We’ll be launching one pretty soon.
To be honest, we have a CLI tool that’s part of the CI. But it’s our personal opinion that a graphical interface would have made things much easier at the start.