Date
1 - 15 of 15
Puzzle with Hardened Runtime entitlement
|
Graham Cox
I have an app I’d like to notarize for distribution outside the app store.
To do this, it requires the hardened runtime entitlement. I have added that in the project settings. When I try and submit the app for notarization, it says “hardened runtime not enabled”. But it is:  I have no idea what’s going on, or how to fix this. I’m using Xcode 11.0 One thing that does seem odd, there is no “<app>.entitlements” file in the project. Changing settings in the Xcode UI doesn’t add such a file. Is this the problem? —Graham |
|
|
|
Jack Brindle
Hardened Runtime is not currently a requirement for Notarization, but it appears that you have to submit the app using the command-line tool for notarization to happen properly. All my attempts at submitting using the Xcode archive method forces me to enable hardened runtime. I have not attempted at submission using Xcode 11, but when submitting with Xcode 10, I have had no problems with hardened runtime so far.
toggle quoted message
Show quoted text
By the way, it appears that hardened runtime causes issues within Apple’s frameworks related to input monitoring. With it, we were not able to get the input monitoring prompt to appear. Removing it allowed our apps to operate properly. These apps do extensive work with BLE keyboard control. So, you might want to use the command line method for submission to get around this, at least until the requirements change in January. Jack
|
|
|
|
Jon Gotow
Have you got any helper applications (including those embedded in Sparkle or other frameworks)? Chances are it's actually complaining about one of those.
toggle quoted message
Show quoted text
- Jon On Oct 31, 2019, at 7:25 PM, Graham Cox <graham@...> wrote: |
|
|
|
Graham Cox
Yes, I have Sparkle and some 3rd party frameworks. I’ve checked the box that permits these to be loaded even though they’re signed by another developer.
toggle quoted message
Show quoted text
I have another app with much the same source code, settings and embedded frameworks. I was able to get that one notarized, even using the Xcode built-in tool. There’s somethng different about this one, but I can’t tell what it is. —Graham On 1 Nov 2019, at 12:34 pm, Jon Gotow <gotow@...> wrote: |
|
|
|
Jon Gotow
On Oct 31, 2019, at 9:15 PM, Graham Cox <graham@...> wrote: Yes, have you turned on hardened runtime for the AutoUpdate app?  I have another app with much the same source code, settings and embedded frameworks. I was able to get that one notarized, even using the Xcode built-in tool. There’s somethng different about this one, but I can’t tell what it is. - Jon |
|
|
|
Jack Brindle
Have you checked the Notarization report? That will tell you exactly why it failed.
toggle quoted message
Show quoted text
Jack On Oct 31, 2019, at 8:15 PM, Graham Cox <graham@...> wrote: |
|
|
|
Graham Cox
Yes ,this is what it says, which is what I said in my original message here 2019-11-01 03:54:51 +0000 Distribution items ineligible: Error Domain=IDEDistributionMethodDeveloperIDErrorDomain Code=1 "Hardened Runtime is not enabled." UserInfo={NSLocalizedDescription=Hardened Runtime is not enabled., NSLocalizedRecoverySuggestion="Ortelius 2.app" must be rebuilt with support for the Hardened Runtime. Enable the Hardened Runtime capability in the project editor, test your app, rebuild your archive, and upload again.} Except, as far as I can tell, the Hardened Runtime is enabled. —Graham |
|
|
|
Graham Cox
I misspoke - I’m not using Sparkle. I’m using Devmate - I thought that used Sparkle internally, but I’m not sure. Anyway my other app that uses Devmate notarizes with no issues. I cannot see any difference in the two targets. —Graham
|
|
|
|
Jack Brindle
The Notarization process is recursive, in that it works its way down the application structure and checks each part as it goes. If you have applications embedded in your app it will check those, and will give you a report for them as well as the top app. Your report shows the top level app being rejected, not something embedded inside. This assumes the Ortelius 2.app is not embedded inside uninstaller program. In our case, we do embed inside an installer, and have several apps embedded in our overall package, so our notarization reports tend to be extensive, with entries for each subpart.
toggle quoted message
Show quoted text
In our case, because of how we build the applications (we have about 7 that had to be Notarized), we use the command line method for both signing and notarization. Hardened Runtime is part of the code sign process; I don’t remember it adding an entitlement file to our apps (although it could. I’ll have to check). In any case, we are not currently adding hardened runtime because one of the embedded apps (from a third-party developer) was not properly signed. As I noted before, hardened runtime is not a current Notarization requirement, although Notarizing through Xcode still causes it to be required. I wonder if your application code signing is being redone, removing the hardened runtime that was previously performed. Jack
|
|
|
|
Shane Stanley
On 1 Nov 2019, at 12:25 pm, Graham Cox <graham@...> wrote:
I had no problem in Xcode 10, but in the one project where I turned the hardened runtime on for the first time in Xcode 11, I had to make sure it was on in Build Settings as well as in the Signing & Capabilities tab. -- Shane Stanley <sstanley@...> <www.macosxautomation.com/applescript/apps/>, <latenightsw.com> |
|
|
|
Graham Cox
I checked that, and it’s turned on in the build settings.
toggle quoted message
Show quoted text
There’s another oddity, which is probably the real cause. In “signing and capabilities”, I have it set for Xcode to manage automatically. I can choose by company, but the menu for the Signing Certificate won’t let me choose ‘Development’ - it just refuses to select it and remains set to ’None’.  Also, when I do a build, I get this warning:  If I uncheck ‘Automatically manage signing’, then it needs a provisioning profile I don’t have. I could probably create one, but it seems that Apple need me to change the bundle identifier so I can do that! I simply don’t get the interaction between all these things - it just seems like a bunch of random hoops I have to jump through, with little rhyme nor reason. Changing the bundle identifier is going to break (AGAIN!!!) the continuity of updates of my app with my customers. I’m getting really sick of that, and so are they. —Graham
|
|
|
|
Quincey Morris
This isn’t, by any chance, one of those “ancient” apps that use an app ID whose prefix ISN’T your developer team ID? If so, that might have something to do with why it doesn’t work.
toggle quoted message
Show quoted text
|
|
|
|
Leo
I don't have an answer to your particular situation, sadly, but man do I understand your pain!
I can only mention two things: -As far as I understand, provisional profiles are not required for Mac apps at all -From my experience, for non-MAS apps, I recommend to deselect "Automatically manage signing" and do it manually with a script (I use an AppleScript droplet). May I also advise to submit a bug to Apple (unless you already did of course). The time - and resources - we waste because of this poorly designed pseudo-security mumbo-jumbo is absolutely astonishing. That's only my view, of course. Leo |
|
|
|
Sak Wathanasin
That and the dozen or so pop-ups asking for permission that appear as soon as our app launches - all it does is condition the user to press "Allow". Regards Sak |
|
|
|
Leo
On Mon, Nov 4, 2019 at 03:52 AM, Sak Wathanasin wrote:
Oh yeah. "Apple Event sandboxing" must be the dumbest idea Apple came up with in the area of "security" so far. Only causes countless hassles to both users and developers. Leo |
|
|