which was not happening with a Juce version of around mid October.
I just found this in my logfiles, after having updated the normally detached Juce submodule.
I have not set or changed anything in my Jucer files for signing, because this is a later task in my builds, after the Universal binaries are made.
That is the point where I now get failures, because the Intel and Silicon binaries are already “signed” (not with proper settings, but that’s not interesting atm).
The pipeline uses the Xcode command line tools to build the plugin flavours.
Does this maybe ring a bell with a Juce developer?
I saw some recent changes in the Projucer code, but I can’t figure out quickly if empty fields can now lead to something like this:
Signing Identity: "-"
In the mean time I’m reverting my Juce submodule a few weeks back in time 
At a Juce commit from 26 October it works again as before.
Cheers
Presumably your failure occurs when trying to codesign the binaries yourself?
Use the --force Luke
ps. I don’t know how to word this without it sounding “snarky”, and that is not the intention at all, it’s a genuine inquiry: were you not able to find anything about this with a forum search? This issue has popped up a few times, and trying to find it myself now I couldn’t get the right search terms with a valid answer in the 1st few results, which suggests to me that the forum search is basically unfit for purpose for how most people use a search feature. 
edit: I really can’t craft any search term, even in DDG with site:forum.juce.com to find the answer here that’s been given before, so I totally don’t blame you for not finding it yourself.
Just to be explicit, if you have an error whilst trying to sign a binary because it is already signed, just add --force to the codesign arguments and all will be well.
I wrote my observation above from a pipeline that runs everyday, from sources to installers.
I ran into this issue after trying the latest Juce tip.
Indeed, my signing fails because the compile/build parts have - after this Juce update - “decided” to add a signing step.
After reverting my Juce branch to say early October, the issue is gone again. No more attempts to sign my binaries after building them.
I have not changed anything to my Projucer files, nor the pipeline scripts, nor my certificate, etc.
Why should I suddenly start to force-sign my binaries if the “change” is clearly related to Juce?
That would really start messing up this troubleshooting, wouldn’t it?
Oh well, my builds are running again. I was asking if this maybe rang a bell with a Juce developer.
For the why, there’s a link to the commit that introduced the change in post below.
1 Like
Wow, thanks for showing me this.
I hope I didn’t offend you with what I wrote, as mentioned it really wasn’t the intention but the question is difficult to word without it coming across like that.
I may have also misunderstood exactly what is the issue. It was my understanding that unless you give Projucer specific details of which certificate details to use then it will “ad-hoc” sign the binaries in order for the newer macOS versions to not baulk when given un-signed stuff to load.
Absolutely no offense, sorry for my parts. I was a bit hurried…
I am not using Projucer settings for signing at all - I leave those fields empty.
That was actually part of my surprise. I run Powershell scripts in my build pipeline and signing is just one of them - so, imagine that you suddenly see “something else” signing as well…
Cheers
1 Like
