macOS, CEF, and notarization

Having problems with building or using CEF's C/C++ APIs? This forum is here to help. Please do not post bug reports or feature requests here.

macOS, CEF, and notarization

Postby mic » Mon Jan 07, 2019 4:52 pm

Does CEF plan to address code-signing, hardened-runtime support, and other issues related to the Apple notarization process? What is the recommended path for apps that embed the CEF framework and also need to be notarized?
mic
Mentor
 
Posts: 82
Joined: Fri Jan 29, 2016 12:59 pm

Re: macOS, CEF, and notarization

Postby magreenblatt » Tue Jan 08, 2019 3:49 am

Code signing is already possible. I’m not sure what you’re referring to by “hardened-runtime support, and other issues related to the Apple notarization process.”
magreenblatt
Site Admin
 
Posts: 12409
Joined: Fri May 29, 2009 6:57 pm

Re: macOS, CEF, and notarization

Postby mic » Thu Jan 10, 2019 11:11 am

By "code signing is already possible", do you mean that it is the responsiblity of the developer using CEF to code sign the framework, including all the third-party code it uses?

Here is a link regarding macOS notarization, which Apple plans to require in the near future for apps not distributed via the App Store:
https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution

Apps which embed the CEF framework will need to be code signed in their entirety (all binaries, bundles, frameworks, etc.) In addition, all binaries will need to opt in to the "hardened runtime", which adds security restrictions and requires any exceptions to be specifically requested in the entitlements file.

Will CEF provide support for this at some point? Even the CEF demo apps will be affected once the requirement is in place.
mic
Mentor
 
Posts: 82
Joined: Fri Jan 29, 2016 12:59 pm

Re: macOS, CEF, and notarization

Postby magreenblatt » Thu Jan 10, 2019 3:08 pm

What type of support are you seeking? Individual app developers of course need to provide their own signing certificates.
magreenblatt
Site Admin
 
Posts: 12409
Joined: Fri May 29, 2009 6:57 pm

Re: macOS, CEF, and notarization

Postby mic » Thu Jan 10, 2019 4:42 pm

I do understand how to code sign, but I assumed (perhaps incorrectly) that CEF would need to code sign the framework, and would need to implement and test support for the hardened runtime, in order to support notarization. I assumed this would be necessary, if for no other reason than to support the CEF demo apps, once notarization becomes a requirement.

Such support would presumably result in a framework built using the binary distribution that is ready to go for notarization, or at least serve as a guide for third-party developers trying to embed the framework in their apps.

It sounds like you are saying that developers using CEF are expected to sign the framework themselves. Doing this properly for notarization requires signing the complete hierarchy, from the innermost binaries and bundles to the outermost. Can CEF provide guidance on doing this correctly for the framework?

If the CEF framework does not support the "hardened runtime", then it won't be possible for apps using it to support notarization. Can CEF provide guidance on whether/when this support will be available?
mic
Mentor
 
Posts: 82
Joined: Fri Jan 29, 2016 12:59 pm

Re: macOS, CEF, and notarization

Postby magreenblatt » Thu Jan 10, 2019 5:11 pm

Yes, we should provide guidance on how to properly sign the application. Currently there are threads on this forum about that topic but no official documentation.

Presumably Chromium will also require a “hardened runtime” configuration. We should inherit that configuration in CEF. If you believe that something supported by Chromium is missing from CEF please file a bug.
magreenblatt
Site Admin
 
Posts: 12409
Joined: Fri May 29, 2009 6:57 pm

Re: macOS, CEF, and notarization

Postby magreenblatt » Thu Jan 10, 2019 5:17 pm

You can watch https://bugs.chromium.org/p/chromium/is ... ?id=850193 for updates on Chromium hardened runtime support.
magreenblatt
Site Admin
 
Posts: 12409
Joined: Fri May 29, 2009 6:57 pm

Re: macOS, CEF, and notarization

Postby G0apher » Fri Jul 19, 2019 11:09 am

Seems the issue above is fixed - So is there a CefClient/CefSimple example (Cef demo apps) that use the new hardened runtime entitlements on macOS? Or that will happen after the above fix makes it to a stable release branch? Thanks for any pointers on where to follow that up.
G0apher
Techie
 
Posts: 13
Joined: Sat Sep 22, 2018 12:16 am

Re: macOS, CEF, and notarization

Postby magreenblatt » Fri Jul 19, 2019 11:28 am

It should be possible to enable hardened runtime entitlements with CEF 75. CEF sample apps do not demonstrate code signing.
magreenblatt
Site Admin
 
Posts: 12409
Joined: Fri May 29, 2009 6:57 pm

Re: macOS, CEF, and notarization

Postby mic » Fri Jul 26, 2019 2:36 pm

If we use the sample app cefsimple.app as an example, and follow Apple's instructions for code signing:

Code: Select all
codesign --force --options runtime --sign "Developer ID Application: <name>" --timestamp --verbose "Chromium Embedded Framework.framework/Libraries/libEGL.dylib"

codesign --force --options runtime --sign "Developer ID Application: <name>" --timestamp --verbose "Chromium Embedded Framework.framework/Libraries/libGLESv2.dylib"

codesign --force --options runtime --sign "Developer ID Application: <name>" --timestamp --verbose "Chromium Embedded Framework.framework/Libraries/libswiftshader_libEGL.dylib"

codesign --force --options runtime --sign "Developer ID Application: <name>" --timestamp --verbose "Chromium Embedded Framework.framework/Libraries/libswiftshader_libGLESv2.dylib"

codesign --force --options runtime --sign "Developer ID Application: <name>" --timestamp --verbose "Chromium Embedded Framework.framework"

codesign --verify --deep --strict --verbose=2 "Chromium Embedded Framework.framework"

codesign --force --options runtime --sign "Developer ID Application: <name>" --timestamp --verbose "cefsimple Helper.app"

codesign --verify --deep --strict --verbose=2 "cefsimple Helper.app"

spctl --assess -vvvv --type execute "cefsimple Helper.app"

codesign --force --options runtime --sign "Developer ID Application: <name>" --timestamp --verbose "cefsimple.app"

codesign --verify --deep --strict --verbose=2 "cefsimple.app"

spctl --assess -vvvv --type execute "cefsimple.app"


Then we appear to have a properly code-signed app, with the hardened runtime enabled. Note that we are not supporting the macOS sandbox in this case.

However, while the result will execute fine in macOS 10.13, the helper app will crash in macOS 10.14 before the first page is rendered, with a crash log like the following:

Code: Select all
Process:               cefsimple Helper [1268]
Path:                  /Users/USER/Desktop/*/cefsimple.app/Contents/Frameworks/cefsimple Helper.app/Contents/MacOS/cefsimple Helper
Identifier:            cefsimple Helper
Version:               0
Code Type:             X86-64 (Native)
Parent Process:        cefsimple [1264]
Responsible:           cefsimple Helper [1268]
User ID:               501

Date/Time:             2019-07-26 11:01:38.226 -0500
OS Version:            Mac OS X 10.14.6 (18G84)
Report Version:        12
Bridge OS Version:     3.6 (16P6568)
Anonymous UUID:        B7B3BF9C-9F8B-CAA0-6FFE-484A1179DDF5


Time Awake Since Boot: 8100 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, 0x0000003427a02040
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace CODESIGNING, Code 0x2

kernel messages:

VM Regions Near 0x3427a02040:
    Memory Tag 255         0000003427a01000-0000003427a02000 [    4K] ---/rwx SM=NUL 
--> Memory Tag 255         0000003427a02000-0000003427a7f000 [  500K] r-x/rwx SM=COW 
    Memory Tag 255         0000003427a7f000-000000342f96b000 [126.9M] ---/rwx SM=NUL 

Thread 0 Crashed:: CrRendererMain  Dispatch queue: com.apple.main-thread
0   ???                              0x0000003427a02040 0 + 224003104832
1   org.chromium.ContentShell.framework   0x0000000108c82438 0x108631000 + 6624312
2   org.chromium.ContentShell.framework   0x0000000108c8102e 0x108631000 + 6619182
3   org.chromium.ContentShell.framework   0x0000000108cf949d 0x108631000 + 7111837
4   org.chromium.ContentShell.framework   0x0000000108fc412b 0x108631000 + 10039595
5   org.chromium.ContentShell.framework   0x0000000108f8b080 0x108631000 + 9805952
6   org.chromium.ContentShell.framework   0x0000000108f24297 0x108631000 + 9384599
7   org.chromium.ContentShell.framework   0x0000000108f24297 0x108631000 + 9384599
8   org.chromium.ContentShell.framework   0x0000000108f21b40 0x108631000 + 9374528
9   org.chromium.ContentShell.framework   0x0000000108f218cd 0x108631000 + 9373901
10  org.chromium.ContentShell.framework   0x0000000108a1169c 0x108631000 + 4064924
11  org.chromium.ContentShell.framework   0x0000000108a113db 0x108631000 + 4064219
12  org.chromium.ContentShell.framework   0x00000001086a37ba 0x108631000 + 468922
13  org.chromium.ContentShell.framework   0x000000010d6bff7b 0x108631000 + 84471675
14  org.chromium.ContentShell.framework   0x000000010d690460 0x108631000 + 84276320
15  org.chromium.ContentShell.framework   0x000000010d690dbd 0x108631000 + 84278717
16  org.chromium.ContentShell.framework   0x000000010d690f6a 0x108631000 + 84279146
17  org.chromium.ContentShell.framework   0x000000010e4f3735 0x108631000 + 99362613
18  org.chromium.ContentShell.framework   0x000000010e4f357e 0x108631000 + 99362174
19  org.chromium.ContentShell.framework   0x000000010e4f4ba0 0x108631000 + 99367840
20  org.chromium.ContentShell.framework   0x000000010e4eaeb7 0x108631000 + 99327671
21  org.chromium.ContentShell.framework   0x000000010e4ead12 0x108631000 + 99327250
22  org.chromium.ContentShell.framework   0x000000010dfeea72 0x108631000 + 94100082
23  org.chromium.ContentShell.framework   0x000000010dfed714 0x108631000 + 94095124
24  org.chromium.ContentShell.framework   0x000000010a60a480 0x108631000 + 33395840
25  org.chromium.ContentShell.framework   0x000000010ac96235 0x108631000 + 40260149
26  org.chromium.ContentShell.framework   0x000000010acfaef1 0x108631000 + 40673009
27  org.chromium.ContentShell.framework   0x000000010ac96235 0x108631000 + 40260149
28  org.chromium.ContentShell.framework   0x000000010acb026f 0x108631000 + 40366703
29  org.chromium.ContentShell.framework   0x000000010acb07b3 0x108631000 + 40368051
30  org.chromium.ContentShell.framework   0x000000010acb2403 0x108631000 + 40375299
31  org.chromium.ContentShell.framework   0x000000010aca51aa 0x108631000 + 40321450
32  org.chromium.ContentShell.framework   0x000000010acb1d6f 0x108631000 + 40373615
33  com.apple.CoreFoundation         0x00007fff3dc96683 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
34  com.apple.CoreFoundation         0x00007fff3dc96629 __CFRunLoopDoSource0 + 108
35  com.apple.CoreFoundation         0x00007fff3dc79feb __CFRunLoopDoSources0 + 195
36  com.apple.CoreFoundation         0x00007fff3dc795b5 __CFRunLoopRun + 1189
37  com.apple.CoreFoundation         0x00007fff3dc78ebe CFRunLoopRunSpecific + 455
38  com.apple.Foundation             0x00007fff3fedd7df -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 280
39  org.chromium.ContentShell.framework   0x000000010acb2911 0x108631000 + 40376593
40  org.chromium.ContentShell.framework   0x000000010acb173f 0x108631000 + 40372031
41  org.chromium.ContentShell.framework   0x000000010acd37f8 0x108631000 + 40511480
42  org.chromium.ContentShell.framework   0x000000010ee83813 0x108631000 + 109389843
43  org.chromium.ContentShell.framework   0x000000010a7c219f 0x108631000 + 35197343
44  org.chromium.ContentShell.framework   0x000000010ce240cb 0x108631000 + 75444427
45  org.chromium.ContentShell.framework   0x000000010ce24a09 0x108631000 + 75446793
46  org.chromium.ContentShell.framework   0x000000010a7c1614 0x108631000 + 35194388
47  org.chromium.ContentShell.framework   0x000000010aa252c0 0x108631000 + 37700288
48  org.chromium.ContentShell.framework   0x0000000108633640 cef_execute_process + 192
49  org.cef.cefsimple.helper         0x0000000102fb3180 main + 160
50  libdyld.dylib                    0x00007fff69bcf3d5 start + 1

(rest of log omitted)


Any idea what the problem could be? Does the helper app have some kind of entitlements requirements in macOS that are not documented? This seems to be implied by https://bugs.chromium.org/p/chromium/issues/detail?id=850193.

That issue seems to be closed now, so can you help with the necessary requirements for code-signing and enabling the hardened runtime for the CEF demo apps, so that the result will not crash in macOS 10.14? One poster on the Chromium issue asked "When will these changes in the helper (entitlements) be available in a release CEF build?" and the reply was "Sorry, I don't know. CEF is a separate downstream project."

There is a lot of pressure to notarize right now, with the macOS 10.15 release already in beta. Thanks for any help you can provide.
mic
Mentor
 
Posts: 82
Joined: Fri Jan 29, 2016 12:59 pm

Next

Return to Support Forum

Who is online

Users browsing this forum: No registered users and 85 guests