I’m going out of my mind here trying to notarise a plugin installer. I’m signing the plugins using my Apple developer ID. After signing, I double check to see that it went Ok with the following command
codesign --verify --deep --verbose myplugin.vst
this returns:
myplugin.vst/Contents/MacOS/myplugin: valid on disk
myplugin.vst/Contents/MacOS/myplugin: satisfies its Designated Requirement
And this is the same for the VST, VST3 and .component versions. No problems there. Then I build the installed (using Packages) and sign it using productsign - this time using my Apple installer ID. I verify the installer .pgk using:
pkgutil --check-signature mypluginInstaller.pkg
It returns:
Status: signed by a developer certificate issued by Apple for distribution
Signed with a trusted timestamp on: 2022-03-05 10:59:16 +0000
So far so good. Then I run xcrun altool to upload an notarise. Many moments later I get a report to say that none of the contained plugins have a valid signature?
issues": [
{
"severity": "error",
"code": null,
"path": "mypluginsInstaller.pkg/myplugin_AU.pkg Contents/Payload/Library/Audio/Plug-Ins/Components/myplugin.component/Contents/MacOS/myplugin",
"message": "The signature of the binary is invalid.",
"docUrl": null,
"architecture": "x86_64"
},
I’m completely stumped. The plugins all pass codesign verification locally. I’ve been able to successfully notarise plugins before, but never a plugin installer, although I don’t think that is the issue here.
I’d really appreciate suggestions on this. I’m going around in circles.
Quick update, I was able to notarise all the individual plugins, but when I try to notarise the installer it gives me errors. Can it be that the installer is modifying the binaries in some way which is screwing with their codesigning? I might try with pkgbuild/productbuild and see if I have any better luck with that.
When I was still using Packages, it was handling all signing requirements automatically (with appropriate settings), and was showing a visual seal icon to indicate this. I didn’t need to manually use productsign. Maybe that’s was causing a mess? I’m now using pkgbuild and productbuild as well.
I tried both enabling and disabling the product signing in Packages. Each led to the same result. The more I read about this, the more it looks like pkgbuild and productbuild are the way to go.
Oh wow, 10 minutes with pkgbuild and productbuild and everything is signed and notarised
Thanks for all the input! I am tempted to add “don’t use Packages” to the title of this thread but I really can’t say if it was user-error on my part that was causing the problem.
I think by default packages will try to strip out files such as .DS_Store files and this can change the bundle and thus impact the signing, just untick this in the GUI.
That’s not necessary if you then distribute (and notarize) a PKG.
You only need to notarize the “top-level” container. For example, we distribute a DMG which contains a PKG that installs the plugins. We only notarize the DMG, everything inside gets notarized as well, including the plugins. Same if you only distribute a PKG.
The notary service generates a ticket for the top-level file that you specify, as well as for each nested file. For example, if you submit a disk image that contains a signed installer package with an app bundle inside, the notarization service generates tickets for the disk image, installer package, and app bundle.
Just for the records, I’m using the same workflow you’ve described (Packages for generation of the installers, but codesign and productsign called manually from a script for signing) and I’m not getting these errors.
If you want to further investigate whether and how Packages is tampering with the content of the plug-in bundles, what I’d do is to use a tool like Suspicious Package to extract the plug-in bundle from the installer, then compare it “directory-wise” (e.g. with kdiff3) with the original plug-in bundle that you had on disk after the codesign step.
While we’re on the subject, I have another related question.
Does anyone have a working example of using pkgbuild/productbuild to create plugin installers? I wanted to switch away from packages for a while but ran into all kinds of little problems along the way.
Here’s what I’m using now. I’m not the most bash fluent, but this does the trick. You obviously need a ‘Developer ID Application’ and ‘Developer ID Installer’ credentials. This produces the most barebones of installers. One thing I’m unclear on, is whether I should be using --deep when signing the plugins. Because I’m signing them at the container level I assumed I do. But @kunz doesn’t seem to, so maybe it’s not required.
#!/bin/bash
echo ""
echo "=============================================================================================================="
echo "==== Code signing and notarisation script ===="
echo "=============================================================================================================="
echo "==== ===="
echo "==== Usage: ===="
echo "==== ./createPkgs.sh PluginName DeveloperId AppleID AppPass Identifier Version ===="
echo "==== ===="
echo "==== PluginName = Plugin name without any extension - will try to create pkgs for VST/VST3/AU ===="
echo "==== Developer ID = \"Your Name (NNNNNNNNNN)\" ===="
echo "==== Apple ID = emailaddress@somewhere.com ===="
echo "==== AppPass = app-sepecific password generate at https://appleid.apple.com/ ===="
echo "==== Identifier = com.MyCompany.name ===="
echo "==== Version = version number, i.e, 1.0.1 ===="
echo "=============================================================================================================="
echo ""
if [ "$EUID" -ne 0 ]
then echo "Error: Please run this command as root using sudo..."
echo ""
exit
fi
if [[ $# -lt 6 ]]; then
echo "Error: Illegal number of parameters..."
echo ""
exit
fi
PLUGIN_NAME=$1
DEVELOPER_ID=$2
APP_PASS=$3
APPLE_ID=$4
IDENTIFIER=$5
VERSION=$6
#use pkgbuild to build the plugin installers - and sign with Apple Developer ID
pkgbuild --install-location /Library/Audio/Plug-Ins/Components --identifier "$IDENTIFIER"au --version 1.0.2 --component "$PLUGIN_NAME.component" "$PLUGIN_NAME"_au.pkg
sudo codesign -s "Developer ID Application: $DEVELOPER_ID" "$PLUGIN_NAME".component --timestamp --force --deep
pkgbuild --install-location /Library/Audio/Plug-Ins/VST --identifier "$IDENTIFIER"vst --version 1.0.2 --component "$PLUGIN_NAME".vst "$PLUGIN_NAME"vst.pkg
sudo codesign -s "Developer ID Application: $DEVELOPER_ID" "$PLUGIN_NAME".vst --timestamp --force --deep
pkgbuild --install-location /Library/Audio/Plug-Ins/VST3 --identifier "$IDENTIFIER"vst3 --version 1.0.2 --component "$PLUGIN_NAME".vst3 "$PLUGIN_NAME"vst3.pkg
sudo codesign -s "Developer ID Application: $DEVELOPER_ID" "$PLUGIN_NAME".vst3 --timestamp --force --deep
productbuild --synthesize --package "$PLUGIN_NAME"_au.pkg --package "$PLUGIN_NAME"_vst.pkg --package "$PLUGIN_NAME"_vst3.pkg distribution.xml
productbuild --distribution distribution.xml --resources Resources/ ""$PLUGIN_NAME".pkg"
productsign --sign "Developer ID Installer: $DEVELOPER_ID" "$PLUGIN_NAME".pkg "$PLUGIN_NAME"_installer.pkg
xcrun altool --notarize-app --primary-bundle-id "$IDENTIFIER" --username $APPLE_ID -password $APP_PASS --file "$PLUGIN_NAME".pkg
Thanks a lot. That looks simple. Time to remove packages from the toolchain.
Is there something special in the distribution.xml and do I need to specify that it supports native ARM when I execute this on 10.15.7 (so that the installer does not want to install Rosetta 2)?
Running the productbuild --synthesize --package generates the distribution.xml for you. It’s my understanding that you can then modify it with various customisation. I guess the Packages software provides a UI wrapper to this.
This is a good question. I’m not sure. But in my tests, users have been able to install my test packages on both Intel and arm64 machines. FWIW, I’m producing the packages on an M1 mac.
What I’ll do eventually is grab the version number, plugins formats, and plugin name from my CMakeLists.txt file. For now I’m still in the testing phase of the installer. Most people have reported no issues, but there may be an issue with Catalina where there has been a report of an ‘unidentified source’ warning on install. It can be got around by ‘right-clicking’ and opening that way, but it shouldn’t be popping up at all.
