Did something change related to code-signing in 6.1.3 Projucer?

The Projucer
2

I found another post where a similar issue was encountered (here: AU fails and strip symbols ) but I’ll continue my post here, as it’s not only for AU.

So, for the AU and VST, I could work around the issue by modifying my release script and doing as mentioned in that other thread: using codesign --remove-signature before doing the strip -x -S and then signing as I was already doing after that.

But now since today with JUCE 6.1.3 the extra Apple codesign does cause 2 issues for my AAX version…
So in the post-build script that I have setup in the Projucer, I copy the plugin presets in the aaxplugin bundle and then sign the bundle with wraptool.
Now with JUCE 6.1.3, after that Xcode post-build script, Xcode signs the bundle as well via codesign.
And this is what I get (this is on an Intel Mac, building x86_64 and arm64, and using Xcode 12.5.1 and wraptool 5.4.1):

  1. Pro Tools doesn’t load the plugin any longer saying that the plugin is not a valid AAX 64-bit plugin.
  2. When I submit my installer to Apple for notarization, it is being rejected: “Package invalid” with status code 2. And when looking at the log it’s clear that it’s the AAX plugin that is causing the rejection:
{
  "logFormatVersion": 1,
  "jobId": "97082ff2-**********************",
  "status": "Invalid",
  "statusSummary": "Archive contains critical validation errors",
  "statusCode": 4000,
  "archiveFilename": "SaltyGrainInstaller_1.2_20211209.pkg",
  "uploadDate": "2021-12-09T20:17:23Z",
  "sha256": "5d262cd**********************",
  "ticketContents": null,
  "issues": [
    {
      "severity": "error",
      "code": null,
      "path": "SaltyGrainInstaller_1.2_20211209.pkg/SaltyGrainInstaller.pkg Contents/Payload/Library/Application Support/Avid/Audio/Plug-Ins/SaltyGrain.aaxplugin/Contents/MacOS/SaltyGrain",
      "message": "The binary is not signed with a valid Developer ID certificate.",
      "docUrl": null,
      "architecture": "x86_64"
    },
    {
      "severity": "error",
      "code": null,
      "path": "SaltyGrainInstaller_1.2_20211209.pkg/SaltyGrainInstaller.pkg Contents/Payload/Library/Application Support/Avid/Audio/Plug-Ins/SaltyGrain.aaxplugin/Contents/MacOS/SaltyGrain",
      "message": "The signature does not include a secure timestamp.",
      "docUrl": null,
      "architecture": "x86_64"
    },
    {
      "severity": "error",
      "code": null,
      "path": "SaltyGrainInstaller_1.2_20211209.pkg/SaltyGrainInstaller.pkg Contents/Payload/Library/Application Support/Avid/Audio/Plug-Ins/SaltyGrain.aaxplugin/Contents/MacOS/SaltyGrain",
      "message": "The binary is not signed with a valid Developer ID certificate.",
      "docUrl": null,
      "architecture": "arm64"
    },
    {
      "severity": "error",
      "code": null,
      "path": "SaltyGrainInstaller_1.2_20211209.pkg/SaltyGrainInstaller.pkg Contents/Payload/Library/Application Support/Avid/Audio/Plug-Ins/SaltyGrain.aaxplugin/Contents/MacOS/SaltyGrain",
      "message": "The signature does not include a secure timestamp.",
      "docUrl": null,
      "architecture": "arm64"
    }
  ]
}

Note that I do use a valid Developer ID certification and timestamp when I sign with wraptool (and this still works when using JUCE 6.1.2).

So, I think the new extra Apple signing after the wraptool signing somehow breaks things both for Pro Tools and for Apple notarization.

@reuk Would it be hard to add back a possibility in the Projucer to not do any signing at all from Xcode? Perhaps via a special string for the code signing identity in the Projucer (instead of my current empty string, which seems to lead to “Sign for running locally”)?

1 Like