My app access to microphone permission when it launches, I'm pretty sure that's the problem. I codesigned with the permissions for mic
I also noticed and I mention in a previous post in this thread, that I had to sign all the .mxo and it worked on one computer but it does not work anymore. I was wondering if I have to code sign also all the info.plist from all the .mxo or if I should add the entitlements on the info.plist of the app info.plist
All the entitlements I have:
And I'm adding now camera which I don't need. But... Seriously Max would aggressively ask for the camera? I'll check that then.
Dan, thanks so much for your support and everything you've done. I've been able to successfully codesign and I can confirm that adding the --deep flag without--options runtime fixes the missing objects issue.
However, I haven't been able to notarize. My log contains multiple entries for the following errors:
-"The binary is not signed with a valid Developer ID certificate."
-"The signature does not include a secure timestamp."
-"The executable does not have the hardened runtime enabled."
The first thing I should clarify is that I'm still on High Sierra (10.13.6).
If that's the issue, I'll upgrade, but wanted to see if I'm missing something else before I do.
Joel, you must include the --options runtime flag; that's what enables hardened runtime status, which is required for notarization.
I'm not positive re: 10.13, but I don't think that should matter.
My best suggestion is to follow Ben Bracken's/Cycling's Notarization post linked above in Ben's last message. When followed exactly, it has yielded good results for me and several other people. When it comes to which entitlements to include in your entitlements file, the best strategy is to include more than required at first, and see if your app runs correctly. At that point, you can begin to successively try to remove ones you don't think you need, and keep retesting in-between.
I'm getting an "unknown exception" error in the terminal when I include the entitlements command. I'm not sure what's going on - is it because something in that file is parsed incorrectly? (I started by just copying in all the strings from Ben Bracken's post above.) Or is the .entitlements file something I have to get from Apple?
Would love to look at an example .entitlements file if someone has one and is willing to share!
I'm starting to think I don't have the first command right. I'm using:
codesign -s "Apple Development: Joel Corelitz"
because it matches what's in my keychain.
codesign -s “Developer ID Application: Joel Corelitz” , which is what I see in all the step-by-step guides,has always given me:
“Developer: no identity found
And I realize this is a basic question I'm not sure exactly what to put in quotes.
I'm an admin on a company account. I've tried the company name too but anything following "Developer ID Application: gives me the same error.
Yes, that means you're not pointing to the correct certificate. Open up the Keychain Access app (it's in Applications/Utilities), click on My Certificates in the left hand pain under Category, and if you don't see "Developer ID Application: YOUR NAME", then you don't have the correct certificate installed. If it is there, then be sure it doesn't have a little red "x" on its icon, and that it has not expired.
That's it - it's the wrong certificate. Looks like creating that kind of certificate isn't allowed as admin.
Maybe I need account holder access?
Thanks again - this week has been quite a crash course and I'm really grateful for this thread!
Can you post:
* the full command you are using to codesign
* the full contents of your entitlements file
* the exact name of your Developer ID Application certificate, as seen in Keychain Access. For example, mine is called "Developer ID Application: Daniel Nigrin"
That was my mistake - probably the result of banging my head against this and trying with without commas, putting my name in, everything I can think of. But I get the same result even without the space. Seems like anything containing "Developer isn't working.
I was just able to successfully notarize. Finally figured out the issue. For some reason, copying & pasting the codesign command from the Notepad was causing errors in the Terminal. I manually typed in the same command, character-for-character, and it was successful.
So - is there any definitive solution to the missing objects issue? I'm having that issue on Catalina but not Mojave. My patch is all factory objects and 2 simple abstractions, but the app is missing a lot more than those
Here's what I've tried (with no success), based on what I've read on this thread -
-Skipping the stapling step
-Signing, notarizing a DMG, stapling, then signing again without the --options runtime flags but then not notarizing the DMG and sharing that.
If you have any question about whether you are using the right entitlements or not, try building a simple test standalone with just a handful of objects in it, and sign with the minimal set of entitlements you've got above. Then see if that works. If not, it means that something else in the sequence of steps is not going correctly.
ok - I've been following the steps on that post too. It must be an entitlements issue. I'm only skipping steps to troubleshoot based on some (older) posts in this thread that suggested notarization and --options runtime were breaking the app, but it seems like maybe that's cleared up now.
Ok, so I had successfully signed and notarized a version of my standalone on January 4th. I have made a new version that I am now trying to do the same thing. As far as I know, I am using the same steps, and I have not made any significant changes to my patch that would change anything in terms of entitlements etc. Now, my notarization is being declined!! I know Apple has been announcing some policy changes..... is it possible the policy changes are responsible for this? I also just now tried signing/notarizing a copy of the standalone that was originally successful and that has also been just denied. The rejection letter talks about checking a log for trouble shooting, but can't figure out how to do this in terminal. Any thoughts?
I've written this issue before but I got no answer and I have not found the fix yet. When I turn on the DSP (should ask mic permission but it does not), max crashes:
Report file: https://www.dropbox.com/s/myi2mhagvvu12r6/Liveloopreport.pages?dl=0
31 thread that cause the crashing: Thread 31 Crashed:: Dispatch queue: com.apple.root.default-qos
I tried with deep and no deep and I read the documentation of Apple which says the following:
"Important: While you use the --deep option for verification to mimic what Gatekeeper does, it is not recommended for signing. During signing, if you have nested code, and if you are signing manually, you sign nested code in stages (as Xcode does automatically), starting with the most deeply embedded components first. You then sign code at the next level of hierarchy, and so on. You work your way outward, finally signing the top level entity that contains all the others. Signing all the components in one shot with --deep is for emergency repairs and temporary adjustments only. Note that signing with the combination --deep --force will forcibly re-sign all code in a bundle"
I did lots of tests and I realized that code signing the .app with --deep flag is not enough. After notarizing was declined, I got the link with all the issues and I figure out that all the .mxo needed to be notarized and also the following files:
Also code signing files separately needs to be from the inside out. So I first code sign the .mxo files, then the two files I mention before and the end the app with all the entitlements mention before.
I also tried adding com.apple.security.app-sandbox for the .mxo as I have a hint that the problem might be from there. When I add this entitlement in the app, it won't open.
I'm really stuck here and I don't know what else to try.
Do you all have access to the mic but just codesign the .app?
@Josep - I've also read that Apple document about not using --deep as we do, but honestly it has never caused me any trouble at all.
What does still seem a bit "off" to me is the number of entitlements you have. You have many that I don't think are applicable to the hardened runtime use case, and rather for the Mac App Store, if memory serves. I'd recommend not including any entitlements that you don't see listed on the bottom of Cycling's post at https://cycling74.com/articles/max-8-1-mac-os-10-15-catalina-support-and-notarization/ , and see if that fixes things.
Finally, re: MSPReWireDevice - are you using ReWire in your app? I usually recommend stripping a standalone of unneeded elements, so if you're not using ReWire, you can get rid of that one... This topic is beyond the scope of this thread though...
I'm still stumped on the missing objects issue. Entitlements seem fine. I have read posts from Cycling that seem to suggest that Hardened Runtime breaks the app and causes the missing objects issue, but since it can't notarize any other way (or be opened any other way in Catalina), it isn't a step it seems like anyone can skip. Is there a possibility it could have something to do with sharing on Dropbox? I've successfully signed, notarized and stapled a test standalone app that runs everywhere but Catalina, where it looks like this:
Here's a link to an example that includes the patch, build script and entitlements file:
Externals can be minimized if for example you're not using some devices. Init has to be untouched, Interfaces can be minimized. Other folders depends on your preferences settings in the standalone obj. Empty folders can be removed. Maxzlib.mxo avoids the gui loss.
@Joel - a few things I noticed and that you could try. I'm not in front of a Catalina machine at the moment (it works fine on 10.13), but assuming that it would fail for me there too:
* Dropbox could potentially be doing something - not necessarily to download your DMG from there, but if you keep your app on there as you are signing it, it might be interfering. If you're not already, try building your app to your Desktop, and then sign, notarize, staple, DMG-ize, etc... to your Desktop as well, and *then* move the final DMG to Dropbox.
* In your screenshot, it looks like you're running the app from the mounted DMG image. Try dragging the app to your Desktop, or perhaps even your Applications folder. Just wondering if in Catalina there might be new restrictions on running the app from a virtualized image or something.
* I noticed in your standalone object that you don't include the Max database - I usually leave this checked. Longshot, but worth a try. I double checked in my projects and I *don't* have this option checked. So cross this one off your list of things to try...
Pulling out my hair here.... hours of time going down the drain... checking my notarization log, and it is saying "The binary is not signed with a valid Developer ID certificate." or "The binary is not signed."...... I'm following instructions exactly, I've checked both my keychain access and my apple developer account, everything looks good. Running "codesign -vvv --deep --strict" tells me everything looks good! I checked the notarization log of my previous standalone which was approved back in January, and I was actually getting all the same messages, the only difference being that in January, instead of it being an "error", it was a "warning". So somehow I was able notarize and distribute an app that was signed with an invalid Developer ID, and my users were able to open it? Something is strange here..... do I need to talk get in touch with Apple technical support at this point?
Ok, turns out part of my problem was addressed already above, I had the wrong developer certificate (needed to get the one starting in Developer ID Application). So that took care of some of the errors. But it is still rejecting my app I because the .mxo's are not getting signed. Here is what I am using:
codesign -s "Developer ID Application: My Name" --options runtime --timestamp --force --deep --entitlements "path_to_entitlements" -f "path_to_app"
You said you have not needed to sign them individually.... is there something I am doing wrong?
It is unchecked.... only option I see is to delete all the unnecessary .mxo's and manually sign the ones I need, but this would be quite frustrating because I am doing beta testing, which means I have to make regular updates, a lot of work every time I want to get a new beta to my testers. Other people here seem to be getting by without doing extra signing of the mxo's, is that because they don't need to be signed, or is it because the "deep" is not working for me as it is for others?
Just a note here regarding Apple's tightening of their requirements. We now have to sign every external object, framework, dylib, etc (basically any executable binary) in the Max app, so you may have to do the same.
Ok, deleted most of the mxo's (kept the same as keepsound's screenshot above), manually signed the ones that were left, plus also had to manually sign executable in the MacOS folder....... and.... success!! Finally! It seems other people around here are having success (post feb 3) without signing the mxo's.... if this is true, how is it possible?
Wow, OK that's good to know. I apologize if I may have been confusing the picture - whereas I *thought* I had been successfully signing with a single codesign command and --deep post February 3, I just checked, and the last one I released was in fact earlier than that (January 3 actually).
All that said, what a royal PITA all that signing! Maybe some smart person (or Cycling! :-) ) can develop a script or something?
PITA indeed! But not sooooo bad once deleting the extra undeed mxo's. I just had to do 7 separate manual signings. But, the problem, as I said before, is beta testing. I can't so easily just send updates, quite a lot of hoops to jump through. Also, I have been using QuickLicense/AddLicense to protect my software (couple years went into this app!!), and that is no longer getting past notarization. I have emailed the company, hopefully they can resolve, which I think involves them just adding hardened runtime to their code sign feature (couldn't have success myself manually doing it). Thank you for all your help, Dan..... I spent quite a lot of hours figuring this out, but it would have been waaaaaaay more hours without your help.
I couldn't get it to work..... but strangely....... ClickInstall CAN get something wrapped with QuickLicense/AddLicense past notarization. And I have no idea why because it seems somehow they are doing it without hardened runtime (the hardened runtime option actually didn't work!). I tried to get their tech support to explain to me just how that was possible, but the guy didn't know. Quite a mystery. I didn't purchase ClickInstall yet, but I did try it with their 10 day trial. Going into another round of development now, might have to buy it later, unfortunately its is very expensive.
Yeah it is expensive I have QuickLicense and I was worried about new OS blocking it. I guess the only way is to buy click install dang it. I am interested in getting this to work I am trying to redo some Max apps that are 32 bit up to 64bit and I noticed this advisory about Catalina. I feel like I spend more time doing this kind of stuff then actual development. Let us know how it goes I still am worried about even upgrading to Catalina I am still on Sierra with Max 7 and QL8. Looks like I need QL9 Max 8 Catalina and Click Install to actually distribute anything. I wish I could just use Max 7 and QL8 somehow..
I wish they would just update QuickLicense so that it would work, but who knows when that will happen! Maybe it couldn't hurt to write to them and bug them about it. The more pressure they get the more likely they would be to change.