Codesigning woes

Possibly not quite what you’re after:

de_currentTag=$(git describe --tags)
rm -f Source/GitVersion.h
echo "#pragma once" >> Source/GitVersion.h
echo "constexpr const char* GIT_VERSION=\"$de_currentTag\";" >> Source/GitVersion.h

Done before the build steps, this allows me to include the git commit id into the plugin e.g. on an about popup and the installer name.

4 Likes

I’m not out of the woods yet it seems. Although my installer passes notarisation, users are still getting hit with:

image

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?

sst-plugininfra/scripts/installer_mac at main · surge-synthesizer/sst-plugininfra · GitHub Here’s a script based on the surge installer for a relatively generic juce project

shortcircuit-xt/basic-installer.cmake at main · surge-synthesizer/shortcircuit-xt · GitHub Here’s the cmake rules we use in shortcircuit to gather up the built things and stage then for that

That combined with a secret in our pipeline means we generate signed notarized installers automatically

2 Likes

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. :pensive:

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.

Here is the link:

Edit: looks like a different 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 :joy:

1 Like

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.

1 Like

Thanks guys, this is extremely useful info!

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.

4 Likes

Great script! Working great and creates installers without any issues. One thing that I couldn’t get to work is this part in distribution.xml:

<license file="License.txt" />
<readme file="Readme.rtf" />

Where am I supposed to place these files? I tried every sub directory in the build folder but couldn’t get them to show during installation.

They should go in the folder specified by --resources at productbuild, in that particular script seems to be the 3rd argument given to the script.

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?

1 Like

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}.

1 Like

Yeah the (more complicated multi-plugin plus resources) surge fork of this script does exactly that.

2 Likes

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? :thinking:
Screen Shot 2023-03-09 at 15.04.49

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.

1 Like

I think it would be nice for new users. I guess it wouldn’t just be limited to JUCE apps?

1 Like

I code sign in XCode from the producer, but a drag and drop notarisation tool would be groovy.

1 Like