QtWebEngine signing issues

krobinson · wrote on 28 Apr 2019, 02:26

For some reason I have recently started having issues with the QtWebEngine. It seems to not be loading. I am a little confused because I didnt change xcode or the qt version, im not sure why the issue started now. However I have tracked it down to my signing step. If I build the application and test the .app on another system it works fine. As soon as I sign the .app, the QtWebEngine stops loading. Here is the command I am using.

sudo codesign --deep --force --verify --verbose --sign "Developer ID Application: ***" --options runtime Output/MyApp.app

krobinson · wrote on 2 May 2019, 02:55

I have been around the block and back with this now. This seems to be related enabling hardened runtime. Im not publishing to the Mac Store, but I was using the new process of notarizing the application so I had to enable this. I have found a lot of info of similar situations.

https://mediaarea.net/blog/2018/02/14/QtWebEngine-MacAppStore
https://forum.qt.io/topic/78518/sandbox-app-for-the-mac-app-store-with-qt-5-8-and-qtwebengineprocess/13
https://lists.qt-project.org/pipermail/development/2017-May/029881.html

I have tried pretty much everything and it still breaks when I enable the hardened runtime. I can get it to run fine using the steps in the first article but then if I go back and sign the QtWebEngineProcess.app with hardened runtime enabled I see the following error.

ERROR:mach_port_broker.mm(43)] bootstrap_look_up: Permission denied (1100)

From the articles I believed this was from the BaseBundleID method not being set, but I did that.

I feel like I'm close, but also running in circles. If anyone has any tips on what I might still be doing wrong it would be appreciated.

krobinson · wrote on 2 May 2019, 05:24

With a little more work on it tonight I can get the main application signed with hardened runtime enabled and it still works. As soon as I sign the QtWebEngineProcess with hardened runtime enabled it quits working. At this point it seems to be crashing.

SEGV_MAPERR 000000000010
 [0x000105ed6f56]
 [0x7fff69dddb5d]
 [0x00010d091fe0]
 [0x00010784c761]
 [0x0001078484ba]
 [0x00010784827e]
 [0x000107bc38b9]
 [0x00010795c58b]
 [0x000107bcc4d4]
 [0x00010748b1d1]
 [0x000107451d54]
 [0x0001088659c3]
 [0x00010886660d]
 [0x00010885ec4f]
 [0x0001087dbf0b]
 [0x00010840ff1e]
 [0x00010840e52c]
 [0x00010840dcb4]
 [0x00010840d6cc]
 [0x000108440246]
 [0x000105e75328]
 [0x000105e74436]
 [0x0001052e6e76]
 [0x00010529ff54]
 [0x7fff69bf83d5]
[end of stack trace]

krobinson · 5 Aug 2019, 14:54

I found a solution to this issue after much trial and error. I am fairly certain this will need to be done for anyone who is attempting to notarize a macOS application using the QtWebEngine. Hopefully this will save someone some time in the future.

The solution for me was to sign the QtWebEngineProcess with with the com.apple.security.cs.disable-executable-page-protection exception. Here is the process.

Sign the main application with the following command

sudo codesign --deep --force --verify --verbose --sign "Developer ID Application: ***" --options runtime MyApp.app

Create an entitlements file for the QtWebEngineProcess

<?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.disable-executable-page-protection</key>
    <true/>
</dict>
</plist>

Sign the QtWebEngineProcess with the following command

sudo codesign --force --verify --verbose --sign "Developer ID Application: ***" --entitlements QtWebEngineProcess.entitlements --options runtime MyApp.app/Contents/Frameworks/QtWebEngineCore.framework/Helpers/QtWebEngineProcess.app/Contents/MacOS/QtWebEngineProcess

Sign the main executable with the following command

sudo codesign --force --verify --verbose --sign "Developer ID Application: ***" --options runtime Output/MyApp.app/Contents/MacOS/MyApp

After following these steps I am able to successfully notarize the application.

Edit: Added more details

sztomi · wrote on 31 Jul 2019, 14:23

@krobinson thank you so much for taking the time to share your solution, this saved me a lot of headaches. I knew I'd probably need to add some entitlements to WebEngine, but I had no idea what.

dalamber · wrote on 5 Sept 2019, 04:29

@krobinson thank you so much for this!

kdg82 · wrote on 17 Sept 2019, 08:34

I tried what is suggested in this topic, but it didn't help - QtWebEngineProcess still crashes. I created another topic: https://forum.qt.io/topic/106949/qtwebengine-signing-issues

mjsmithers · 21 Apr 2020, 19:12

@krobinson a HUGE thank you from me also. I would never have figured this out.

BTW My procedure is slightly different. I

run macdeployqt
sign the .app with the hardened runtime and with the deep option
use your entitlements step (above) with force to replace the signing just on QtWebEngineProcess
notarize the .app,
put the .app in a DMG,
sign the DMG with the hardened runtime, then
notarize the DMG.

Everything works! Thanks again.

miskuu · wrote on 7 Feb 2020, 19:55

@krobinson Thank you, Sir! Apple really likes to make devs lives harder every day.

nkqhxj · wrote on 12 Apr 2020, 14:33

It's doesn't work form me, console output is: code object is not signed at all
In subcomponent: Myapp/Contents/PlugIns/mediaservice/libqavfmediaplayer.dylib.
but when i try sign with -deep, it's crash again.

markuz · wrote on 17 Apr 2020, 07:01

Hi,

and thanks, this post helped me a lot. From a technical point of view:

Reading this, Apple says 'The system causes an app that attempts to directly modify
sections of its own executable files on disk to forcefully exit.'

What kind of technique or practice is it, that makes
qtwebengine run into Apple's executable memory protection issues?
Is it possible to nail this down on a certain piece of code?

Adressing this issue, has this code changed from Qt 5.9 to 5.12?

Thanks,
-Markus

PSI_lbc · wrote on 18 Apr 2020, 15:37

Create an entitlements file for the QtWebEngineProcess
<?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.disable-executable-page-protection</key>
<true/>
</dict>
</plist>

Sign the QtWebEngineProcess with the following command
sudo codesign --force --verify --verbose --sign "Developer ID Application: ***" --entitlements QtWebEngineProcess.entitlements --options runtime MyApp.app/Contents/Frameworks/QtWebEngineCore.framework/Helpers/QtWebEngineProcess.app/Contents/MacOS/QtWebEngineProcess

Where exactly does one "Create an entitlements file for the QtWebEngineProcess"?

Can this process be done once or must it be done each time you create a build or run MacDeployQt?

Can the QtWebEngineProcess.entitlements file be added to the QtWebEngineCore.framework ?

If so, where does it go exactly?

Should it be in the Helpers folder? Inside the QWebEngineProcess app.bundle?

If in the QWebEngineProcess app.bundle, what folder? In Contents where the info.plist is? In Resources?

Why can't the ..<key>com.apple.security.cs.disable-executable-page-protection</key>..be added directly to the QWebEngineProcess plist file?

sk-working · wrote on 20 Apr 2020, 02:33

Not working for me. 5.12.5 & 5.12.8

As soon as I sign QtWebEngineProcess with "runtime" option and entitlements QtWebEngineProcess crashes.

I even listed all available entitlements - but no difference.

Cannot text with 5.14.x because of bug: https://bugreports.qt.io/browse/QTBUG-75262

PSI_lbc · wrote on 21 Apr 2020, 19:12

@mjsmithers said in QtWebEngine signing issues:

@krobinson a HUGE thank you from me also. I would never have figured this out.

BTW My procedure is slightly different. I

run macdeployqt

sign the .app with the hardened runtime and with the deep option

use your entitlements step (above) with force to replace the signing just on QtWebEngineProcess

notarize the .app,

put the .app in a DMG,

sign the DMG with the hardened runtime, then

notarize the DMG.

Everything works! Thanks again.

Thanks! This worked for me with a slight modification. The first time I tried it there was an error on the entitlement signing step. Because of a path problem.

sudo codesign --force --verify --verbose --sign "Developer ID Application: ***" --entitlements QtWebEngineProcess.entitlements --options runtime MyApp.app/Contents/Frameworks/QtWebEngineCore.framework/Helpers/QtWebEngineProcess.app/Contents/MacOS/QtWebEngineProcess

The actual path to the QtWebEngineProcess after MacDeployQt is :

MyApp.app/Contents/Frameworks/QtWebEngineCore.framework/Versions/5/Helpers/QtWebEngineProcess.app/Contents/MacOS/

discovered when doing a "GetInfo" on the QtWebEngineProcess executable. Not sure why the "/Versions/5/" is not visible in finder but is on the GetInfo, and maybe it will change with different versions of MacDeployQt or OSX..IDK.

FWIW..The codesign line is less cluttered by doing a "cd' to the folder with the executable and entitlement files..

cd '/pathto/MyApp.app/Contents/Frameworks/QtWebEngineCore.framework/Versions/5/Helpers/QtWebEngineProcess.app/Contents/MacOS/'
sudo codesign --force --verify --verbose --sign "Developer ID Application: ***" --entitlements QtWebEngineProcess.entitlements --options runtime QtWebEngineProcess

MrGuo · wrote on 29 Apr 2020, 09:08

Here is my step:

~/Qt5.10.1/5.10.1/clang_64/bin/macdeployqt my.app -dmg

sudo codesign --deep -f -v -s "Developer ID Application: XXX" -o runtime my.app

sudo codesign -f -v -s "Developer ID Application: XXX" --entitlements QtWebEngineProcess.entitlements -o runtime
my.app/Contents/Frameworks/QtWebEngineCore.framework/Helpers/QtWebEngineProcess.app/Contents/MacOS/QtWebEngineProcess

use DropDMG create my.dmg

sudo codesign -f -v -s "Developer ID Application: XXX" -o runtime my.dmg

xcrun altool --notarize-app -t osx -f my.dmg --primary-bundle-id "XXX" --username "XXX" --password "XXX"

xcrun altool --notarization-info "RequestUUID" -u "XXX" -p "XXX"

xcrun stapler staple my.dmg

entitlements file is the same as above, works fine on macos 10.15.3

AmyXS · wrote on 23 Jul 2020, 09:42

@krobinson Thanks so much for sharing this solution!!! I'm so glad I found this post after determining that codesigning with hardened runtime causes WebEngine issues. You've saved my day!!!

rdowell · wrote on 18 Sept 2020, 22:17

Having this same issue with a QtWebEngine application, but while re-signing QtWebEngineProcess with the entitlements file as shown above does work for signing the app, QtWebEngine is still crashing if I try to run it:

Process:               QtWebEngineProcess [24905]
Path:                  /Applications/Toolbox.app/Contents/Frameworks/QtWebEngineCore.framework/Versions/5/Helpers/QtWebEngineProcess.app/Contents/MacOS/QtWebEngineProcess
Identifier:            QtWebEngineProcess
Version:               ???
Code Type:             X86-64 (Native)
Parent Process:        Toolbox [24821]
Responsible:           Toolbox [24821]
User ID:               503

Date/Time:             2020-09-18 15:38:32.961 -0600
OS Version:            Mac OS X 10.15.6 (19G2021)
Report Version:        12
Anonymous UUID:        0C2B5E8B-1960-EECA-3F0E-16C355B027FB


Time Awake Since Boot: 4400 seconds

System Integrity Protection: enabled

Crashed Thread:        0  CrRendererMain  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (Code Signature Invalid)
Exception Codes:       0x0000000000000032, 0x0000002aafe05a60
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace CODESIGNING, Code 0x2

Based on a comment in @kdg82 's thread, I tried adding additional entitlements to the QtWebEngineProcess to mimic the entitlements required by Chrome/Chromium, but that doesn't have any effect. I've seen some indication from looking at posts about other non-Qt projects having similar issues that there may be an entitlement inheritance setting that also needs to be updated?

Tim Angus · wrote on 18 Dec 2020, 11:53

@krobinson You, sir, are a steely-eyed missile man. Saved me so much time.

For what it's worth, the console output I got when I was experiencing this issue was:

#
# Fatal process OOM in CodeRange setup: allocate virtual memory
#

Just to add to Google's index of variations of "QtWebEngine not working fatal process oom".

Thanks again!

J0Nes · wrote on 6 Jan 2021, 09:52

Thanks a ton! This was my issue as well, see https://forum.qt.io/topic/122388/qtwebenginecore-on-macos-fatal-process-out-of-memory-failed-to-reserve-memory-for-new-v8-isolate

If you stumble upon this error "Fatal process out of memory: Failed to reserve memory for new V8 Isolate" - read this thread carefully :)

jazzalex · 5 Feb 2022, 14:42

Thanks a lot for this thread !

It really helped, however (three years later), for me it was simpler than described in the thread:

Hardened runtime was not the issue – I just need to add the above mentioned key into my entitlements file and this already did the job. At the end I signed this way:

codesign --options=runtime --entitlements ./entitlements.xml --deep ./soundjack.app -s "my developer ID"

without having the app crash afterwards and being able to notarize.

Best

Alex