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

The Projucer
1

As master was recently updated to JUCE 6.1.3, I was trying to build a few things with that new version, and I noticed the following:

(1) When I run my release script after the build (to prepare all binaries, manual, presets, etc… and create my installer package), I am now getting these warnings:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip: warning: changes being made to the file will invalidate the code signature in: /Users/ktanghe/Documents/Code/SampleSumo/KTSoundProjects/SoundProjects/Applications/Plugins/SaltyGrain/Builds/MacOSX/build/Release/SaltyGrain.component/Contents/MacOS/SaltyGrain (for architecture x86_64)
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip: warning: changes being made to the file will invalidate the code signature in: /Users/ktanghe/Documents/Code/SampleSumo/KTSoundProjects/SoundProjects/Applications/Plugins/SaltyGrain/Builds/MacOSX/build/Release/SaltyGrain.component/Contents/MacOS/SaltyGrain (for architecture arm64)

This happens when my release script does this:

xcrun strip -S -x “$AUBinary”

So I symbol-strip the binaries, then do a few things, and then later in the script I sign them with codesign.

This used to work fine in 6.1.2 without these warnings, and it looks like for some reason the Xcode project is now set to sign my binaries (I can see a line “Sign SaltyGrain.component 0.1 seconds” in the build log), whereas it wasn’t before the update to JUCE 6.1.3.
In the Projucer, the “Code-Signing Identity” is still empty (and I actually didn’t change anything to the .jucer setup file, I only opened it and re-saved the project in the newly built Projucer).

(2) I also noticed that the AAX build also seems to get signed now (“Sign SaltyGrain.aaxplugin 0.1 seconds” in the build log), and that happens after the post-build script, in which I call wraptool for the AAX target of my plugin. Doesn’t this break the wraptool signing now?

1 Like
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
3

For reference, the commit that introduced the new behavior is

1 Like
4

Thanks for pinning that down!

From that code change, it looks like a “-” string in Xcode is used to indicate the “sign to run locally” modality.

So, perhaps it would have been more transparent to just use the string from the Projucer as-is (unless I’m missing a good reason to do it the way it was done now):

  • if the identity string in Projucer is empty, then also in Xcode no code signing happens (right?)
  • if the identity string in Projucer is “-”, then in Xcode this means “sign for running locally” (correct?)
  • if the identity string in Projucer is anything else, then also in Xcode that string is used as specified in the Projucer

And the Projucer could also still set it to “-” by default for new Projucer projects if that would be better.

But I’m probably missing something here.

1 Like
5

Yeah, I’m in the same boat. I don’t really understand why “Sign to run locally” is a problem, but it is - and there’s currently no way to stop Projucer setting the “-” in all targets every time we regenerate the xcode project.
I guess we can hack the projucer to stop it…

1 Like
6

Same issue here
Looking at the XCode target properties it seems that the new Projucer changes the whole Signing section in Build Settings, so it’s impossible to bypass CodeSign

1 Like
7

@reuk Could you please have a look at this on Monday? Thanks!

1 Like
8

I’m taking some time off over the next couple of weeks, so although I’ll probably keep an eye on the forum I probably won’t be able to look at this until Tuesday/Wednesday. Hope that’s alright!

2 Likes
9

Since CODE_SIGN_IDENTITY change in Projucer 6.1.3 i can not debug in Xcode also. :unamused:

10

Same problem here also :frowning: Please fix :frowning:

11

Notice that i (you can) temporarily resolved the stuff manually editing (evil hack) the Xcode pbxproj.

12

Thanks for your patience. I’ve restored the old behaviour on develop. We’re intending to do another point release with a few fixes very shortly, so this will be on master within the next week or so.

The original change was intended to fix an issue some users were seeing in some PACE tooling, but it seems like the change wasn’t really necessary in the end. Additionally, it’s surprising if the signing step runs after the ‘post build’ steps (potentially damaging any signing ops that run in the post-build), especially if no signing details were supplied! Based on all of that, I think reverting the change is the right move.

Hope that makes sense, and sorry for the inconvenience.

5 Likes
13

Sorry to bump this old thread, but has that re-introduced in J7? I’ve update this morning and since then I’m having the same issues as the OP.

Thanks,
Luca

3 Likes
14

Re-introduced probably in JUCE 7.0.2 just before 7.0.3 (https://github.com/juce-framework/JUCE/commit/8d0afb6939e2cbe55a283ead5936c1fea0ae3a08).

Related: [BUG] App is already signed

1 Like
15

I tried adding codesign --remove-signature before stripping, but now the strip command returns a fatal error

fatal error: file not in an order that can be processed (link edit information does not fill the __LINKEDIT segment): <path to the binary here>(architecture)

EDIT: confirmed that stripping is not working. Symbols are there.
FIX: I removed codesign --remove-signature and added --force to codesign for plugins. Now it works as supposed.