Problem trying to notarize AU v2 plugin installer .pkg

Question

Created Oct ’21

Replies 5

Boosts 0

Participants 2

I have been trying for the last day and a half to try and get an AU .component bundle with no success. The bundle in question is an AU implementation of a .vst3 plugin which I also have a bundle for which notarises without any issue. the AU implementation is achieved with the Steinberg AU wrapper library which implements an AU (v2) component that loads the vst3 plugin implementation contained in a .vst bundle under the Resources folder of the AU component bundle. I code sign and package the bundle with,

codesign --force --options runtime --timestamp --sign "Developer ID Application: ***" HBDynamicsAU.component/Contents/Resources/plugin.vst3/Contents/MacOS/HBDynamicsVST codesign --force --options runtime --timestamp --sign "Developer ID Application: ***" HBDynamicsAU.component/Contents/MacOS/HBDynamicsAU codesign --force --timestamp --sign "Developer ID Application: ***" HBDynamicsAU.component

productbuild --component HBDynamicsAU.component /Library/Audio/Plug-Ins/Components
--root ./presets/AU /Library/Audio/Presets/HarBal/Dynamics/
--timestamp --sign "Developer ID Installer: ***"
HBDynamicsAU-1.0.2.intel.64.pkg

Checking the output of the signing process with,

pkgutil --check-signature HBDynamicsAU-1.0.2.intel.64.pkg

yields,

Package "HBDynamicsAU-1.0.2.intel.64.pkg": Status: signed by a certificate trusted by Mac OS X Certificate Chain: 1. Developer ID Installer: Paavo Jumppanen (***) SHA1 fingerprint: B8 BD FF DC 43 1A 6B 25 BE 39 21 F2 B5 D1 3F C2 D7 B6 0B 1F ----------------------------------------------------------------------------- 2. Developer ID Certification Authority SHA1 fingerprint: 3B 16 6C 3B 7D C4 B7 51 C9 FE 2A FA B9 13 56 41 E3 88 E1 86 ----------------------------------------------------------------------------- 3. Apple Root CA SHA1 fingerprint: 61 1E 5B 66 2C 59 3A 08 FF 58 D1 4A E2 24 52 D1 98 DF 6C 60

which looks fine to me. Also doing,

spctl -a -vvv -t install HBDynamicsAU-1.0.2.intel.64.pkg

yields,

HBDynamicsAU-1.0.2.intel.64.pkg: accepted source=Developer ID origin=Developer ID Installer: ***

which again looks fine. Now if I notarise it I get the following outcome in the log,

logFormatVersion 1 jobId "9127060e-ea60-4044-82e8-ba6a7cd234c6" status "Invalid" statusSummary "Archive contains critical validation errors" statusCode 4000 archiveFilename "HBDynamicsAU-1.0.2.intel.64.pkg" uploadDate "2021-10-04T03:46:59Z" sha256 "17dc1ba78e55349501913ee31648a49850aa996d0c822131cf7625096f5d827c" ticketContents null issues 0 severity "error" code null path "HBDynamicsAU-1.0.2.intel.64.pkg/com.har_bal.HarBal.dynamics_1.0.2.au.pkg Contents/Payload/Library/Audio/Plug-Ins/Components/HBDynamicsAU.component/Contents/MacOS/HBDynamicsAU" message "The signature of the binary is invalid." docUrl null architecture "x86_64"

The file it is complaining about is the AU wrapper dynamic library which is HBDynamicsAU. If I now check that in my bundle (ie. before it was packaged) I get,

codesign --verify --verbose -r- HBDynamicsAU.component/Contents/MacOS/HBDynamicsAU HBDynamicsAU.component/Contents/MacOS/HBDynamicsAU: valid on disk HBDynamicsAU.component/Contents/MacOS/HBDynamicsAU: satisfies its Designated Requirement

so it looks ok. Now to check that nothing is wrong with the package I installed the plugin by double clicking on the .pkg file in finder and then did the codesign check with the installed plugin in place with,

codesign --verify --verbose -r- /Library/Audio/Plug-Ins/Components/HBDynamicsAU.component/Contents/MacOS/HBDynamicsAU /Library/Audio/Plug-Ins/Components/HBDynamicsAU.component/Contents/MacOS/HBDynamicsAU: valid on disk /Library/Audio/Plug-Ins/Components/HBDynamicsAU.component/Contents/MacOS/HBDynamicsAU: satisfies its Designated Requirement

which looks perfectly fine as well. So what gives, why does it fail notarisation when every check you are told to do to debug issues says it is ok. This looks like a bug in the process but I have no idea. The limited information returned through the log is not enough to isolate the problem. How do I fix this and indeed, can I fix this?

regards,

Paavo.

PS - Oh, and to check that it wasn't a problem with the actual dylib I swapped the libraries around in the package so the VST3 one was where the AU one was and visa versa and ran the notarisation again and it it again said the library under HBDynamicsAU.component/Contents/MacOS was the problem (which is now the vast one cos I swapped it) so it clearly has nothing to do with the library.

Boost

Answer 1

DTS Engineer OP

Apple

Oct ’21

In future, please use the Code Block button (or triple backquote delimiters) to denote a code block. That’ll make it easier to read your posts.

You can find my general advice on this front in my Signing a Mac Product For Distribution post. Looking at your code signing commands I spotting a number of places where you deviate from that recommended path. I’m going to give a quick summary here but see that post for more details.

Looking at your code signing commands, it seems that you’re setting the hardened runtime flag. This is only necessary for main executables. For library code like this, you don’t need that flag.

You are not following the nested code rules. plugin.vst3 should be placed in a nested code site, like Contents/PlugIns, not in a site reserved for data.

You are signing HBDynamicsAU twice, one via the executables itself (HBDynamicsAU.component/Contents/MacOS/HBDynamicsAU) and again via the enclosing bundle (HBDynamicsAU.component). This is redundant. When signing bundled code, pass in the path to the bundle, not the path to the bundle’s main executable.

All of the above are problems that need to be fixed but they’re unlikely to be the cause of your specific issue. My best guess on that front is that one or both of your bundles are structured incorrectly. Specifically, a bundle’s Info.plist must contain the name of the bundle’s main executable in its CFBundleExecutable property.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

PaavoJ OP

Oct ’21

Thanks for the feedback. I didn't realise there is a distinction between executables and libraries for hardened runtimes option so thanks for pointing that out. The bundle structure is not one of my choice but the way the Steinberg wrapper library was designed to operate with so I guess I will need to modify that code to account for the structure you recommend.

Are you suggesting the signing of HBDynamicsAU.component is all I need and not the signing of HBDynamicsAU.component/Contents/MacOS/HBDynamicsAU? Does that require the --deep option for signing for that to take place?

I will try your suggestions but I am not certain they will fix the issue. The CFBundleExecutable property is set correctly in the Info.plist. It has to be otherwise the plugin would not work but it does work, despite the structural inconsistencies.

Thanks,

Paavo.

0

Answer 3

PaavoJ OP

Oct ’21

Oh, and I forgot to mention that the structural issue is not likely the cause of the problem. I did suspect that it might have been so I stripped out that embedded .vst3 bundle and it still failed with the same error so It can't be the source of the problem. What I find odd is that the .vst3 bundle (ie. seperate VST3 plugin, not this AU wrapped version) notarises without error but the .component bundle doesn't, even the stripped out one. That seems to suggest that it is something specific to a .component bundle. Does the notarisation work differently for a bundle with extension .component compared with .vst3?

thanks,

Paavo.

0

Answer 4

DTS Engineer OP

Apple

Oct ’21

For those reading along at home, I’ll be helping PaavoJ in a different context.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 5

DTS Engineer OP

Apple

Oct ’21

I wanted to close the loop here for those reading along at home…

This problem was triggered by weird formatting in the code’s Info.plist files. If you’re using a third-party build system to create your product, I encourage you to construct your Info.plist files using Apple tools, like PlistBuddy (see its man page). Alternatively, construct the files in whatever way you want and then convert them to the standard format using plutil -convert.

Oh, and likewise for entitlement files. In fact, that’s an issue that crops up frequently enough that we call it out in Resolving Common Notarization Issues.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0