Bugzilla – Full Text Bug Listing
| Summary: | Specify hardened runtime for Mac app signing | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Lakshmi P Shanmugam <lshanmug> | ||||
| Component: | Releng | Assignee: | Lakshmi P Shanmugam <lshanmug> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | akurtakov, akurtakov, daniel_megert, Ed.Merks, lachambre.adrien, Lars.Vogel, mikael.barbero, satishchinthanippu, sravankumarl, tjwatson | ||||
| Version: | 4.13 | Flags: | Lars.Vogel:
pmc_approved+
sravankumarl: review+ |
||||
| Target Milestone: | 4.13 RC2 | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X | ||||||
| See Also: |
https://git.eclipse.org/r/148750 https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=7d53981078d09b2a60daf841de95b8f5170698b4 https://git.eclipse.org/r/149014 https://git.eclipse.org/r/149025 https://git.eclipse.org/r/149084 https://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=f7cb740c999c7309f4d533d40652426a2860fae3 https://git.eclipse.org/r/149108 https://git.eclipse.org/c/equinox/rt.equinox.binaries.git/commit/?id=4b5a1745f92e2cf7fab324cec5ec6d608e2a553a https://bugs.eclipse.org/bugs/show_bug.cgi?id=561649 |
||||||
| Whiteboard: | |||||||
| Bug Depends on: | 549836 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Lakshmi P Shanmugam
New Gerrit change created: https://git.eclipse.org/r/148750 Gerrit change https://git.eclipse.org/r/148750 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=7d53981078d09b2a60daf841de95b8f5170698b4 The cbi version was not updated to use the new version - 1.1.8-SNAPSHOT (In reply to Lakshmi Shanmugam from comment #3) > The cbi version was not updated to use the new version - 1.1.8-SNAPSHOT New gerrit has been created for this https://git.eclipse.org/r/149014 I'm not a Mac user but I trust Lakshmi (In reply to Lars Vogel from comment #5) > I'm not a Mac user but I trust Lakshmi Thanks Lars for the prompt response! Gerrit has been merged. Reopening as signerUrl too needs to be updated in the pom files. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=550135#c23) New Gerrit change created: https://git.eclipse.org/r/149025 Created attachment 279791 [details]
Error Dialog
I did an update to the latest I-Build I20190906-0410 from I-Build I20190828-1800
After that I could no longer launch Eclipse on my Mac and I got an alert dialog complaining about the libjvm.dylib file not having the JNI_CreateJavaVM.
I then downloaded the I-Build tar.gz for the Mac and noticed that the eclipse native launcher had a different size than the one I currently have, I assume from the update with p2. I copied over the one from the tar.gz into my install and now it can launch again. I'm not sure what went wrong with updating the launcher in this scenario and wonder if the new mac signing stuff could be to blame.
I worry that this error may happen when folks try to update from 2019-06 to 2019-09 release. I'll try that scenario, updating from our 2019-06 to the latest I-Build to see if it fails the same.
Yes, updating from https://download.eclipse.org/eclipse/downloads/drops4/R-4.12-201906051800/download.php?dropFile=eclipse-SDK-4.12-macosx-cocoa-x86_64.dmg to the latest I-Build using p2 causes the same issue. Updating to I-Build I20190903-1410 from I20190902-1800 causes the issue, so something between these two builds is causing the issue. But I'm not sure what because just getting the "good" launcher directly from the download makes it work again. (In reply to Thomas Watson from comment #12) > Updating to I-Build I20190903-1410 from I20190902-1800 causes the issue, so > something between these two builds is causing the issue. But I'm not sure > what because just getting the "good" launcher directly from the download > makes it work again. All Mac binaries were signed by Bug 550677 were first part of Build - I20190903-0605. Another I-build is in progress which will apply the hardened runtime and entitlements to Eclipse.app. May be that will make a difference? (In reply to Lakshmi Shanmugam from comment #14) > Another I-build is in progress which will apply the hardened runtime and > entitlements to Eclipse.app. May be that will make a difference? I can try once it is done, but I don't know why it would make a difference. (In reply to Thomas Watson from comment #15) > (In reply to Lakshmi Shanmugam from comment #14) > > Another I-build is in progress which will apply the hardened runtime and > > entitlements to Eclipse.app. May be that will make a difference? > > I can try once it is done, but I don't know why it would make a difference. May be some entitlements [1] are required for the update to work. [1] https://developer.apple.com/documentation/security/hardened_runtime_entitlements?language=objc New build is available with hardened runtime and entitlements - http://download.eclipse.org/eclipse/downloads/drops4/I20190906-0940/ (In reply to Lakshmi Shanmugam from comment #17) > New build is available with hardened runtime and entitlements - > http://download.eclipse.org/eclipse/downloads/drops4/I20190906-0940/ Same error for me updating from 4.12 to this build. I'm currently using MacOS version 10.14.6. Should see if others see this same issue. (In reply to Thomas Watson from comment #18) > (In reply to Lakshmi Shanmugam from comment #17) > > New build is available with hardened runtime and entitlements - > > http://download.eclipse.org/eclipse/downloads/drops4/I20190906-0940/ > > Same error for me updating from 4.12 to this build. I'm currently using > MacOS version 10.14.6. Should see if others see this same issue. I just tried to update using Import Existing Installation and can reproduce this issue. (In reply to Lakshmi Shanmugam from comment #19) > (In reply to Thomas Watson from comment #18) > > (In reply to Lakshmi Shanmugam from comment #17) > > > New build is available with hardened runtime and entitlements - > > > http://download.eclipse.org/eclipse/downloads/drops4/I20190906-0940/ > > > > Same error for me updating from 4.12 to this build. I'm currently using > > MacOS version 10.14.6. Should see if others see this same issue. > > I just tried to update using Import Existing Installation and can reproduce > this issue. The eclipse executable is not being replaced/updated correctly, not sure why. I had tested the installing new software and it worked fine. @Thomas, please suggest how to proceed for RC2? Error message on running from command line: Error loading /Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/MacOS/libjli.dylib: dlopen(/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/MacOS/libjli.dylib, 265): no suitable image found. Did find: /Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/MacOS/libjli.dylib: code signature in (/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/MacOS/libjli.dylib) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed. (In reply to Lakshmi Shanmugam from comment #20) > (In reply to Lakshmi Shanmugam from comment #19) > > (In reply to Thomas Watson from comment #18) > > > (In reply to Lakshmi Shanmugam from comment #17) > > > > New build is available with hardened runtime and entitlements - > > > > http://download.eclipse.org/eclipse/downloads/drops4/I20190906-0940/ > > > > > > Same error for me updating from 4.12 to this build. I'm currently using > > > MacOS version 10.14.6. Should see if others see this same issue. > > > > I just tried to update using Import Existing Installation and can reproduce > > this issue. > > The eclipse executable is not being replaced/updated correctly, not sure why. > I had tested the installing new software and it worked fine. Are you sure about that? When I update from 4.12 to the latest I see the Eclipse.app/Contents/MacOS/eclipse executable get an updated timestamp and it is a different size than before the update. It is as if it is downloading a version of the executable before it was notarised. Is it possible that the update site has a copy of the binaries before they were notarized? > > @Thomas, please suggest how to proceed for RC2? If I run the eclipse executable from a command shell I get this error: Error loading /Library/Java/JavaVirtualMachines/adoptopenjdk-11-openj9.jdk/Contents/MacOS/libjli.dylib: dlopen(/Library/Java/JavaVirtualMachines/adoptopenjdk-11-openj9.jdk/Contents/MacOS/libjli.dylib, 265): no suitable image found. Did find: /Library/Java/JavaVirtualMachines/adoptopenjdk-11-openj9.jdk/Contents/MacOS/libjli.dylib: code signature in (/Library/Java/JavaVirtualMachines/adoptopenjdk-11-openj9.jdk/Contents/MacOS/libjli.dylib) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed. The eclipse executable is coming from http://download.eclipse.org/eclipse/updates/4.13-I-builds/I20190906-0940/features/org.eclipse.equinox.executable_3.8.500.v20190903-1802.jar that has 46224 09-03-2019 16:09 bin/cocoa/macosx/x86_64/Eclipse.app/Contents/MacOS/launcher So it is not getting the latest. Perhaps something needs touched to get that updated? New Gerrit change created: https://git.eclipse.org/r/149084 I touched the executable feature with https://git.eclipse.org/r/149084 (In reply to Thomas Watson from comment #25) > I touched the executable feature with https://git.eclipse.org/r/149084 Updating to latest via import from existing installation also fails. Is it the same problem? Gerrit change https://git.eclipse.org/r/149084 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=f7cb740c999c7309f4d533d40652426a2860fae3 After updating, the eclipse executable is replaced with eclipse from the update site that is not signed with entitlements. Only eclipse in the downloads is signed with hardened runtime + entitlements. This is causing the problem. We'll check if there is way to have eclipse with entitlements in the the update site too. Else, we'll have to revert all the signed libraries and changes made for signing. New Gerrit change created: https://git.eclipse.org/r/149108 Gerrit change https://git.eclipse.org/r/149108 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.binaries.git/commit/?id=4b5a1745f92e2cf7fab324cec5ec6d608e2a553a (In reply to Eclipse Genie from comment #30) > Gerrit change https://git.eclipse.org/r/149108 was merged to [master]. > Commit: > http://git.eclipse.org/c/equinox/rt.equinox.binaries.git/commit/ > ?id=4b5a1745f92e2cf7fab324cec5ec6d608e2a553a The executable has been signed with entitlements and committed to git. Sravan has started https://ci.eclipse.org/platform/job/eclipse-aggregator-master/1319/ to get a test build. We'll verify if update works once the job completes. (In reply to Lakshmi Shanmugam from comment #31) > (In reply to Eclipse Genie from comment #30) > > Gerrit change https://git.eclipse.org/r/149108 was merged to [master]. > > Commit: > > http://git.eclipse.org/c/equinox/rt.equinox.binaries.git/commit/ > > ?id=4b5a1745f92e2cf7fab324cec5ec6d608e2a553a > > The executable has been signed with entitlements and committed to git. > > Sravan has started > https://ci.eclipse.org/platform/job/eclipse-aggregator-master/1319/ to get a > test build. We'll verify if update works once the job completes. Update works with the test build - https://ci.eclipse.org/platform/job/eclipse-aggregator-master/1319/. Will trigger an I-build. Signed Mac executable binary with entitlements via http://git.eclipse.org/c/equinox/rt.equinox.binaries.git/commit/?id=4b5a1745f92e2cf7fab324cec5ec6d608e2a553a This solved the problem of upgrade. Root cause: In the initial builds we were signing with hardened runtime without entitlements(this gets added to p2 repository). But the sdk app has been signed with entitlements(the executable in dmg has the entitlements). This makes sdk app to work without problems, but when we upgrade the executable gets replaced with executable from repository(which does not have entitlements). this causes error while loading java libs(these require some entitlements to be enabled we are getting OS blocked mmap() call) this in turn throws exception as shown in the attached screenshot. Now with the above commit I have created a new signed executable with all hardened runtime entitlements enabled. New build is available - http://download.eclipse.org/eclipse/downloads/drops4/I20190907-1130/ Verified that update from update-site and existing installation works. Works for me also. Thanks for taking care of this. Hi guys, I have the exact same issue with the eclipse 2019-12 installer, on MacOs 10.15.2: 2019-12-19 15:35:13.179 eclipse-inst[4496:130511] Error loading /Library/Java/JavaVirtualMachines/openjdk-11.0.2.jdk/Contents/MacOS/libjli.dylib: dlopen(/Library/Java/JavaVirtualMachines/openjdk-11.0.2.jdk/Contents/MacOS/libjli.dylib, 265): no suitable image found. Did find: /Library/Java/JavaVirtualMachines/openjdk-11.0.2.jdk/Contents/MacOS/libjli.dylib: code signature in (/Library/Java/JavaVirtualMachines/openjdk-11.0.2.jdk/Contents/MacOS/libjli.dylib) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed. Any chance that something is missing on this build? Thanks (In reply to Adrien Lachambre from comment #36) > Any chance that something is missing on this build? > Thanks This is an issue with your JVM install which is not notarized, not Eclipse. Upgrade to a more recent version. See https://adoptopenjdk.net/?variant=openjdk11&jvmVariant=hotspot or https://github.com/AdoptOpenJDK/homebrew-openjdk (In reply to Mikaël Barbero from comment #37) > > This is an issue with your JVM install which is not notarized, not Eclipse. > Upgrade to a more recent version. See > https://adoptopenjdk.net/?variant=openjdk11&jvmVariant=hotspot or > https://github.com/AdoptOpenJDK/homebrew-openjdk Thanks for your answer, I updated to the latest open jdk 13, which has probably been notarized, but I still have the same issue. I managed to get get and launch the 2019-12 release by downloading directly the package. This issue only appear when I try to use the installer, that's why I'm not sure that the issue come from the JDK. Ed, has the installer been notarized for 2019-12? (In reply to Dani Megert from comment #39) > Ed, has the installer been notarized for 2019-12? Yes. You'll see the notarization logic in the build logs: https://ci.eclipse.org/oomph/job/build-filtered-installer/lastBuild/console https://ci.eclipse.org/oomph/job/integration/lastStableBuild/console Note that the 2019-09 installer *.dmg was also notarized shortly after the release to ensure it would work on the latest MacOS. (In reply to Ed Merks from comment #40) > (In reply to Dani Megert from comment #39) > > Ed, has the installer been notarized for 2019-12? > > Yes. You'll see the notarization logic in the build logs: > > https://ci.eclipse.org/oomph/job/build-filtered-installer/lastBuild/console > https://ci.eclipse.org/oomph/job/integration/lastStableBuild/console > > Note that the 2019-09 installer *.dmg was also notarized shortly after the > release to ensure it would work on the latest MacOS. The problem described here will appear if the signing does not use entitlements. Here are the issue with the above logs 1. https://ci.eclipse.org/oomph/job/build-filtered-installer/lastBuild/console after analyzing this log I found that the Mac app signing uses old url. This signs mac app with hardened runtime but without entitlements. Here is the line where signing is happening https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/releng/org.eclipse.oomph.releng/hudson/postprocess.sh#n55. Looks like this is the job that publishes release version of the installer. 2. https://ci.eclipse.org/oomph/job/integration/lastStableBuild/console Analysis of this log indicates the mac app is signed with entitlements. if the installer from here is published, the problem described should not appear. Please let me know if I missed anything Hi Team, We have an RCP application built on eclipse oxygen 4.7.3. We are using TychoBuild to build our product to generate packages for Mac, Windows and Linux. We are using equinox, swt, emf and datatools modules in our product. and also our product will work with only Java 1.8 and 10. Now, we have to support mac 10.15. For this, our application has be signed and notarized. to do this, what kind of steps we need to follow to make our product work in mac 10.15 system? 1. Do we need migrate to any specific notarized eclipse version (instead of oxygen 4.7.3)for this? or is it okay to continue with oxygen? 2. Do we need to use notarized Java version (java 14 is only notarized from Oracle) only? (In reply to satish Chinthanippu from comment #42) > Hi Team, > > We have an RCP application built on eclipse oxygen 4.7.3. We are using > TychoBuild to build our product to generate packages for Mac, Windows and > Linux. We are using equinox, swt, emf and datatools modules in our product. > and also our product will work with only Java 1.8 and 10. > Now, we have to support mac 10.15. For this, our application has be signed > and notarized. to do this, what kind of steps we need to follow to make our > product work in mac 10.15 system? For building the installer, which is also just an RCP application, we do this post processing: https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/releng/org.eclipse.oomph.releng/hudson/postprocess.sh#n52 So this is not part of the Tycho process but rather a post processing step to convert the *.tar.gz to a signed and notarized *.dmg. > 1. Do we need migrate to any specific notarized eclipse version (instead of > oxygen 4.7.3)for this? or is it okay to continue with oxygen? It's not entirely clearly to me that this old version of SWT works on a newer version of Mac. It seems to me at some point I needed to create a new Mac virtual machine because SWT stopped working. I think you ought to move to a newer version. It might also be the case that the native Mac libraries need to be newer-than-Oxygen ones. I don't know because I always use the latest Eclipse version for any new version of the Installer. In any case, the key point is that you definite need a notarization service that includes the entitlement: curl -O https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/releng/org.eclipse.oomph.releng/hudson/installer.entitlements curl -o signed.zip -F file=@unsigned.zip -F entitlements=@installer.entitlements http://172.30.206.146:8282/macosx-signing-service/1.0.1-SNAPSHOT Without the entitlements, you definitely won't be able to launch. > 2. Do we need to use notarized Java version (java 14 is only notarized from > Oracle) only? Do you distribute this as part of the *.dmg? The native components of eclipse 4.7.3 are not signed with hardened runtime. (A requirement for notarization process). This done from 4.13 and above. There are 2 options for you. 1. To stay on 4.7.3 you need to sign native components with hardened runtime, rebuild eclipse, use rebuilt eclipse to create your RCP application, create signed dmg and notarize. 2. Move to 4.13 and above, build rcp application, create signed dmg and notarize Please note you need to sign executable with hardened runtime and entitlements. Also while creating dmg you need to sign with hardened runtime and entitlements. The native components of eclipse 4.7.3 are not signed with hardened runtime. Is other than any native components that we need to sign stated below? ./eclipse.platform.releng.aggregator/eclipse.platform.swt.binaries/bundles/org.eclipse.swt.cocoa.macosx.x86_64/libswt-pi-cocoa-4932r18.jnilib ./eclipse.platform.releng.aggregator/eclipse.platform.swt.binaries/bundles/org.eclipse.swt.cocoa.macosx.x86_64/libswt-awt-cocoa-4932r18.jnilib ./eclipse.platform.releng.aggregator/eclipse.platform.swt.binaries/bundles/org.eclipse.swt.cocoa.macosx.x86_64/libswt-cocoa-4932r18.jnilib ./eclipse.platform.releng.aggregator/rt.equinox.bundles/bundles/org.eclipse.equinox.security.macosx/libkeystoreNative.jnilib ./eclipse.platform.releng.aggregator/eclipse.platform.resources/bundles/org.eclipse.core.filesystem.macosx/os/macosx/libunixfile_1_0_0.jnilib ./rt.equinox.binaries/org.eclipse.equinox.launcher.cocoa.macosx.x86_64/eclipse_1902.so As of now, we have to stay on 4.7.3, so can you help me on what other native components we need to sign other than list mentioned in previous post. (In reply to satish Chinthanippu from comment #46) > As of now, we have to stay on 4.7.3, so can you help me on what other native > components we need to sign other than list mentioned in previous post. Have you tested if your application based on 4.7.3 launches/works on macOS 10.15? Yes, I have tested. It's installed successfully but while launching, it's giving error as The JVM shared library "/Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/bin" .. doesnt contan the JNI_CreateJavaVM symbol (In reply to satish Chinthanippu from comment #48) > Yes, I have tested. It's installed successfully but while launching, it's > giving error as The JVM shared library > "/Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/bin" .. > doesnt contan the JNI_CreateJavaVM symbol That's exactly the same message as here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=558570 So it seems clear to me you have not notarized with the required entitlements. Note specifically all the comments there about using "codesign -d --entitlements" to check the entitlements of the *.app you want to test are the complete correct required ones. When I execute command "codesign -d --entitlements" - "/Applications/TeradataStudio.app/" is printing only "Executable=/Applications/TeradataStudio.app/Contents/MacOS/TeradataStudio" only printing. no entitlements are printing as mentioned in https://bugs.eclipse.org/bugs/show_bug.cgi?id=558570 (In reply to satish Chinthanippu from comment #50) > When I execute command > "codesign -d --entitlements" - "/Applications/TeradataStudio.app/" > is printing only > "Executable=/Applications/TeradataStudio.app/Contents/MacOS/TeradataStudio" > only printing. no entitlements are printing as mentioned in > https://bugs.eclipse.org/bugs/show_bug.cgi?id=558570 This means the app is not signed with entitlements. So it cannot load unsigned java libraries into the application To resolve this you need to sign your application with entitlements |