Hardened runtime causes app to crash on open. (Signed and notarized) #4040
Comments
|
Confirmed same issue happening to us. I'm not sure what to even do to work around this. |
|
is this the fix? #3926 |
|
Further info: You need at least the following entitlements: Further info from https://medium.com/@TwitterArchiveEraser/notarize-electron-apps-7a5f988406db Make sure to try out starting the app after this process, if some entitlements are missing, the app might be broken after notarization. |
|
@itsthisjustin tried all sorts of entitlements, including the ones above, not the fix. Also tried gatekeeper access to false and afterSign hook to notarize before making the DMG; still not the fix. The only variable that fixes this is turning hardened runtime off; but that means you can't notarize.
|
|
@UdaraJay entitlements got rid of the sign error but yeah my UI crashes on start now |
|
Hey, @itsthisjustin - wondering what MacOS you use? and Xcode version? Curious if it's an xcode issue. |
|
@UdaraJay I installed the latest Xcode beta today actually in order to get notarization working. So 11 beta 3. I'm on OSX 10.14.5. I have this running in Travis CI as well. Update: Tested on xcode 10.2 and same issue |
|
Yes, the issue I'm having in #3989 seems exactly the same, except I'm still using electron 4.2.6 and I'm building on an older Mac (OSX 10.13.6, according to Apple's own documentation this is the minimum version able to notarize apps - and I verified that using Xcode to build a simple native app it works perfectly well). Also, my app doesn't use webpack but only simple old-school html/css/js. Both signature and notarization seems ok on my app, and even the error report seems the same: I tried adding all these entitlements, but with no success: I also verified that the correct entitlements are embedded in the application. Last week I opened a DTS at Apple but even with their help we've not found a solution yet. |
|
@UdaraJay Alright, I've finally got it working. The trick was two fold. First: Set both entitlements and entitlementsInherit in your mac build settings. Here's mine: Then, in my entitlements file, I stripped it down to only what I need. com.apple.security.cs.allow-unsigned-executable-memory is really the key one here. Others mentioned adding another one, but I was back to the signing crash when I did that. |
|
I've tried your same entitlements, but unfortunately my application still crashes with the same symptoms |
|
@matteotomasoni is there any other entitlements you might need? Ive basically found this: If you don't do the entitlementsInherit thing, your app won't load. If you mess up the entitlements with too many or too few, it'll crash with the signing error. For instance if I add the sandbox entitlement I crash with the sign error |
|
@itsthisjustin is there a reason for the |
|
@matteotomasoni ha yeah we are building https://yac.chat. So definitely needs audio. I had the same fear as you and I think ultimately just got lucky. That’s also why the inherit property is so important. I’m not sure who at Apple thinks it’s normal to just crash an app if the entitlements are wrong though. |
|
@itsthisjustin glad you figured it out! I've tried those entitlements and other combination (for both the entitlements and the inheritedEntitlements) with no luck. But I didn't realize having too many entitlements could cause signing errors too, that's important to note! And yea! Truly, I wish there was a way to access more specific errors on code-signing, or at least fail more elegantly. |
Hello, For now I have no idea ... So if someone at a track, I'm interested |
|
This suggestion from @itsthisjustin got me past the startup crash. I'm still having other issues (unable to access web content for starters) but at least things are running. |
|
i too am having a similar problem. cant get past startup crash.
|
|
@starkos @HeberLemus if you don't need any specific entitlements, try removing the entitlements files and let electon-builder set the default one. That's the only way I got signing and notarizing to work on my end. (still not perfect; but it at-least gets the application to run) |
|
@UdaraJay tried that just now, removed the properties "entitlements" and "entitlementsInherit" from the package json under the mac key, still the exact same error also, running "codesign -d --ent :- "Appname.app/Contents/MacOS/Appname" doesnt give back anything if its supposed to set default entitlements update: nevermind, the defaults are being set. in the end, my build is loading with the default entitlements. the other issue i had was that i had set |
|
Perfect! @HeberLemus did it start working? |
|
@UdaraJay yes, no build issues, no startup issues and no later issues thus far. guess my problem really was that one property just like for this update: actually there is one problem. while the file works fine when downloaded to a flashdrive and then mounted onto the mac, the .pkg isnt getting signed so when attempting to open said file it comes back as unidentified developer when attempting to download from the net going to try and see if the AfterAllArtifactBuild hook may let me sign and notarize the .pkg beofre its done update two: so it would seem that signing and getting it notarized works, but stapling does not
my method was
if someone can suggest a cleaner way to do this i greatly appreciate it. update 3: despite Apples documentation that even if a file doesnt have its notarization ticket stapled to it, that it should be able to get the notarization clearance from the net as stated here
the .pkg still refuses to open. any ideas? |
|
@HeberLemus so I had this problem too. If signing and notarizing works anything like dmgs, then you can leave the pkg unsigned and unnotarized and the OS should see the signed and notarized application inside. I couldn't get my pkg to notarize; but I'm using a DMG for distribution currently. |
|
@UdaraJay i also swapped back to dmg, as i asked a coworker to try and use the .pkg and his system refused to open saying unknown developer, much in the same way as if its not notarized. if i downloaded the pkg to a flash and then open the pkg from the flash on the mac after transferring it to a mac, then it would open. but if downloaded from the internet it refused ive run into a different problem now. anytime i attempt to set entitlements other than let the defaults be set the app refuses to run. but i need the camera entitlement for my app to access webcam and audio entitlement to access microphone. any recommendations? |
|
@HeberLemus this may be a real issue, I can't seem to get signing to work using any custom entitlements either. One thing you could try would be to look at what the exact default entitlements are and then try using those + the camera entitlements? |
|
WOW! Thanks for this thread. Totally saved me. Couldn't figure out why |
|
@patrickmichalina did you assign that to both entitlements and entitlementsInherit keys? |
|
I used both but should it be different? "mac": {
"entitlements": "entitlements.mac.plist",
"entitlementsInherit": "entitlements.mac.plist"
} |
|
com.apple.security.files.user-selected.read-write
com.apple.security.cs.allow-unsigned-executable-memory
this is my entitlements. If I delete dylib in project and set "hardenedRuntime": false, it work. but add dylib, it crash on open. |
|
Hi all! Two questions: My MAS app builds and runs fine if I don't add this to the entitlements.plist
Is this this required or not? Can I submit the app to App Store without it? The MAS builds seems to generate an executable AND an installer (PKG). However, the latter uses default icons, text etc and I don't see any options in electron builder docs to set these. |
Please read the documentation of apple carefully, then you'll understand it. |
|
Resolved? I'm facing the same problem. I haved changed my entitlements files many times, added lots of entitlements, but useless. Here is my entitlements.mas.parent.plist <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.app-sandbox</key>
<true/>
<key>com.apple.security.application-groups</key>
<array>
<string>XXX.com.aaa.bbb</string>
</array>
<key>com.apple.application-identifier</key>
<string>XXX.com.aaa.bbb</string>
<key>com.apple.security.files.user-selected.read-only</key>
<true/>
<key>com.apple.security.files.user-selected.read-write</key>
<true/>
<key>com.apple.security.network.client</key>
<true/>
<key>com.apple.security.network.server</key>
<true/>
<key>com.apple.security.cs.allow-jit</key>
<true/>
<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
<true/>
<key>com.apple.security.cs.allow-dyld-environment-variables</key>
<true/>
<key>com.apple.security.cs.disable-library-validation</key>
<true/>
</dict>
</plist>Error Message: |
|
Solved! We now have the MAC (not MAS) hardened runtime working on Apple macOS. I hope this review might help others: The Apple notarising process was spewing out false positives, so there was officially no problem, until our application died when running on a Mac, and created a dump file. Then it was difficult for Apple support to work out what the problem was. Sometime on or before 10th April 2020, Apple (finally) did some upgrading work on their notarising process, an Apple Tech Support chap told me. It meant that we finally got some meaningful error messages, although over a couple of days (9th / 10th) the messages altered. Each run seemed to wipe out the previous 'https://osxapps-ssl.itunes.apple.com/...' logs and made them show the latest results as though they are their own?! The Apple logs eventually had the error "Embedded entitlements are invalid: syntax error near line 1". Their docs claim this means the entitlements file is in a binary format. In order to help the support engineer by providing the binary to which the entitlements had been applied, we had to create a new stand alone Azure (macOS) pipeline since you can't export artefacts from their releases pipelines. And this new pipeline worked like a charm! Notarising passed, and the software opened correctly on the Mac. It seems as though passing the code over from the main Azure (Windows) pipeline to the releases (macOS) pipeline somehow damaged the entitlements.plist file? There is a nagging suspicion that in 6 months time, Apple will suddenly say that there is no problem. One curious anomaly, is that although we're using the exact same Azure pipeline agent specification as before, 10.15, Taccy previously though that the software had been build on macOS 10.13 and now thinks it is 10.15. Or perhaps that is a reflection on the version used by Apple itself to notarise? So the problem is solved. One of the things we've found incredibly frustrating is that Apple do not provide engineer tools to work out what is going on, hence the use of Taccy et al. Frankly, their ecosystem support is nowhere near as good as Microsoft. Our final entitlements file:What did help:Making sure the path to the entitlements file was relative './...' What didn't fix it for us:Endlessly changing the entitlements Hope this is of some use! |
|
Has any one been able to narrow down what caused this crash? Same misery here. Mac Build, Electron-Builder 22.7.0, hardenedRuntime=true, Crash with code signature invalid on app launch. |
|
Got it to build and notarized. Have to use the default entitlement for both main and inherit. Electron-builder: 22.7.0 Any other setting causes code signature invalid error. |
|
Thanks guys! I was starting to go bald already. This is what was happening for me in a project completely unrelated to Electron: I had some binaries (go-flutter-desktop actually) and they loaded a It transpired this action requires Allow Unsigned Executable Memory Entitlement during the codesign operation with Thanks to you lot I figured which entitlement was missing by trial and error. |
|
Incase this helps anyone else, I was having issues with this where I was able to successfully notarize and sign my app but it would crash and close upon opening. I was letting Electron-Builder sign my app for me, but using a custom script after the fact to sign additional files that Apple's notarization would complain about. (As well build and sign a PKG file containing my Electron app.) I realized my script was replacing the existing code signing done by Electron, and was not re-applying the entitlements that I had setup via the package.json file in my Electron workflow. Ultimately I got things working by not using the Electron signing process at all (You can totally get this working via Electron-Builder, I just didn't want to move my automation scripts from my current workflow.). Here are all my settings: Pacakge.json configurations: (build => mac) Entitlements File: (inside my 'build' folder, located at root of my project) Command for Building App via Electron: (Again, I was not using Electron Builder for signing, to use electron builder remove the '-c.mac.identity=null' part. '-m' specifies to build specifically for Mac platform)
My Signing Script Process: In addition to signing the main .app file, I sign all of the following files individually first (deep sign does not seem to do this for me):
For each of these files I sign, I use this command: For the main executable I use: I think the entitlements get inherited from the main app, which is why it seems to work for me not applying the entitlements to all the framework and executable files. Then, to verify: Some Notes About my App's Functionality:
Some Links That Were Helpful: |
|
I was experiencing this problem for over two days and I couldn't find the solution for it online, and I tried everything that I read. Finally, out of desperation, I downloaded the source code for electron-osx-sign and tried to find answers there. What I found was that I could enable debugging by adding this export:
Scrutinizing the debug output, I saw this warning: So, I added the following argument to electron-osx-sign to provide my entitlements:
Running electron-osx-sign again, I saw two new warnings: So, I added the following arguments to electron-osx-sign to provide my entitlements-inherit and entitlements-loginhelper: It appears that I could have skipped adding After doing this, all the warnings went away and I was able to run my signed app, notarize it, and make a DMG installer for it using electron-installer-dmg. Everything is working perfectly now. My entitlements.mac.plist file looks like: <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.cs.allow-jit</key>
<true/>
<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
<true/>
<key>com.apple.security.cs.allow-dyld-environment-variables</key>
<true/>
</dict>
</plist>I'm left with a few questions: package.jsonWhy weren't entitlements and entitlements-inherit picked up from my package.json file? It appears that electron-osx-sign doesn't look for these settings: "mac": {
"icon": "./assets/icons/mac/my-app.icns",
"hardenedRuntime": true,
"entitlements": "./build/entitlements.mac.plist",
"entitlementsInherit": "./build/entitlements.mac.plist",
"target": [
"dmg",
"zip"
]
}entitlements and entitlements-inheritWhat should be in my entitlements file and what should be in my entitlements-inherit file? Should they both be the same? If so, why do we have two different settings? I am unable to find clear and concise documentation on this. When I reviewed Visual Studio Code's signing, they appear to use the same file for both entitlements and entitlements-inherit. entitlements-loginhelperFor a darwin build vs. mas, do I even need this? Should it be empty? I didn't like seeing the warning in the electron-osx-sign debug output, so I added the --entitlements-loginhelper pointing to my entitlements file, which is what electron-osx-sign does anyway, to remove the warning. Best, Brian |
For anyone coming across this mentioned issue ( I just got the same issue after I made my GitLab pipeline take the entitlements file as an artifact from a Windows runner, to then download it to the macOS runner. Somehow that breaks the file, but it's not the encoding (I confirmed that it stayed the same). Downloading the entitlements file as a fresh copy from my git repo works without issues, but that doesn't work for my pipeline details. The quoted comment helped me to figure this one out, though! To fix it you want to use
Running the command to |
|
This was an exceptionally helpful post ! Thank you all for the in-depth comments. In the end, keeping my entitlements as per instructed here: https://medium.com/@TwitterArchiveEraser/notarize-electron-apps-7a5f988406db .. and adding one extra |
|
In my case, removing from my mac plist did the trick. FWIW my target platform was not mas but only mac. |
|
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
I think that is what did it for me as well. I thought I needed the sandbox, but that is a MAS only entitlement. |
|
@mmaietta curious why this was closed on march 8, as far as i can tell its still not possible to create a sandboxed app that also has the hardened runtime enabled. they aren't mutually exclusive security features. |
and others
Versions:
electron:5.0.6electron-builder:21.0.11electron-notarize:0.1.1electron-webpack:2.7.4Working on:MacOS Catalina 10.15 Beta 3 (19A501i)Xcode:Xcode 11 beta 3What I'm trying to do:
Sign and notarize an electron, web-packed, react desktop application for distribution outside the mac store.
Problem and exact case of error:
1/ Verify code signing ✅
2/ Verify code notarization ✅
Target: darwin
Error dump
The text was updated successfully, but these errors were encountered: