Community
Participate
Working Groups
Created attachment 288460 [details] Crash report I am testing Eclipse RCP application builds for MacOS. The application is built for both x86-64 and arm-64 architectures using target of Eclipse 2022-03 (4.23.0). Using PDE build wizard. The x86-64 binaries are good and running with no issues on various computers. However, arm-64 application crashes with an error related to code signing. Attached is the crash report dump. I have verified the signature of the binary produced by the build in /MacOS folder and it looks like this: *** Identifier=SigningServlet-7029897199180243499-unsigned-eclipse Format=Mach-O thin (arm64) CodeDirectory v=20500 size=767 flags=0x10000(runtime) hashes=14+5 location=embedded Signature size=8998 Authority=Developer ID Application: Eclipse Foundation, Inc. (JCDTMS22B4) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=10 Jun 2021 at 14:36:42 Info.plist=not bound TeamIdentifier=JCDTMS22B4 Runtime Version=11.1.0 Sealed Resources=none Internal requirements count=1 size=212 *** Apparently Apple doesn't like this signature.. Or is there another possible issue?
Have you tried building your RCP using Tycho and Maven? I believe the PDE build wizard is no longer supported or maintained. You'll also need to codesign and notarize the app with an Apple developer account and certificate.
(In reply to Phil Beauvoir from comment #1) > Have you tried building your RCP using Tycho and Maven? I believe the PDE > build wizard is no longer supported or maintained. You'll also need to > codesign and notarize the app with an Apple developer account and > certificate. No, we build using the PDE build and it works perfectly fine with all platforms including windows, linuxes and macos. The only issue is the latest aarch64. The application gets notarized with Apple but this isn't the issue here. According to the crash report, the binary produced by the build for aarch64 are signed with Eclipse Foundation developer ID as I have shown above. This signature doesn't seem to be trusted or accepted by this particular Apple machine. My question being is this the issue of the PDE build using a wrong certificate?, or there is something else? Same app built with the same tools runs perfectly fine on MacOS x86-64. Tycho and Maven are really impossible for us to migrate to due to complexity and lack of proper documentation of these rapidly changing tools. I was just hoping to resolve this by simply fixing the signing issue in case it is indeed the problem here.
How are you using the PDE Build? From the .product file "Eclipse product export wizard"?
(In reply to Phil Beauvoir from comment #3) > How are you using the PDE Build? From the .product file "Eclipse product > export wizard"? Yes, using the product file and export wizard for multiple platforms (win32/x86_64, gtk/x86_64, cocoa/x86-64, cocoa/aarch64). All work fine for years.. Except the recently added aarch64.
Did you try exporting for only *one* platform - cocoa/aarch64 ?
opened https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/225
(In reply to Phil Beauvoir from comment #5) > Did you try exporting for only *one* platform - cocoa/aarch64 ? Usually we export to all platforms and there is no issue. But exporting specifically just for cocoa/aarch64 doesn't change anything, the build passes OK.
(In reply to Dmitry Perl from comment #2) > (In reply to Phil Beauvoir from comment #1) > > Have you tried building your RCP using Tycho and Maven? I believe the PDE > > build wizard is no longer supported or maintained. You'll also need to > > codesign and notarize the app with an Apple developer account and > > certificate. > > No, we build using the PDE build and it works perfectly fine with all > platforms including windows, linuxes and macos. The only issue is the latest > aarch64. The application gets notarized with Apple but this isn't the issue > here. According to the crash report, the binary produced by the build for > aarch64 are signed with Eclipse Foundation developer ID as I have shown > above. This signature doesn't seem to be trusted or accepted by this > particular Apple machine. My question being is this the issue of the PDE > build using a wrong certificate?, or there is something else? Same app built > with the same tools runs perfectly fine on MacOS x86-64. > > Tycho and Maven are really impossible for us to migrate to due to complexity > and lack of proper documentation of these rapidly changing tools. I was just > hoping to resolve this by simply fixing the signing issue in case it is > indeed the problem here. We use same certificate for both x86_64 and aarch64 executables. The issue could be something else. Do you use osgi starter kit to build rcp apps? if that is the case I can try notarizing starterkit dmg file.
(In reply to Sravan Kumar Lakkimsetti from comment #8) > We use same certificate for both x86_64 and aarch64 executables. The issue > could be something else. > > Do you use osgi starter kit to build rcp apps? if that is the case I can try > notarizing starterkit dmg file. Thank you! This is what I wanted to verify if it's the same certificate used to sign the binary at build time. The notarized app publicly available below (marked red as beta) if you can check it out on your hardware? https://www.moonlit-software.com/logfaces/web/download/index.php
(In reply to Dmitry Perl from comment #9) > (In reply to Sravan Kumar Lakkimsetti from comment #8) > > > We use same certificate for both x86_64 and aarch64 executables. The issue > > could be something else. > > > > Do you use osgi starter kit to build rcp apps? if that is the case I can try > > notarizing starterkit dmg file. > > Thank you! This is what I wanted to verify if it's the same certificate used > to sign the binary at build time. > > The notarized app publicly available below (marked red as beta) if you can > check it out on your hardware? > https://www.moonlit-software.com/logfaces/web/download/index.php We will need community help in this case. I don't have access to Mac M1 machine. @phil canu you please help us here?
@Sravan happy to help. All my tests show that the binary file generated for mac aarch64 is signed by Eclipse and launches OK. I've tested on M1 with the binary generated from the PDE product wizard and with Tycho. @Dmitry - can you attach or link to just the binary file?
(In reply to Phil Beauvoir from comment #11) > @Sravan happy to help. > > All my tests show that the binary file generated for mac aarch64 is signed > by Eclipse and launches OK. I've tested on M1 with the binary generated from > the PDE product wizard and with Tycho. > > @Dmitry - can you attach or link to just the binary file? Here is the link to the aarch64 binary, it seems to have the same signature as the binary for x86_64 (I tried using local codesign utility) https://www.moonlit-software.com/logfaces/downloads/logfaces
> Here is the link to the aarch64 binary, I downloaded it and used it as the launcher executable for our RCP app and it launched fine.
@Dmitry - When you create your app, do you codesign the "logfaces" binary file (to replace the Eclipse signing) as well as the .dmg file?
(In reply to Phil Beauvoir from comment #14) > @Dmitry - When you create your app, do you codesign the "logfaces" binary > file (to replace the Eclipse signing) as well as the .dmg file? @Phil, thank you for giving it a try. This binary file is created by Eclipse product build wizard. We don't touch it. We do create and sign the dmg for the distribution but this is not an issue.. The crash report I attached was sent to me by one of the end users when they launched the binary. I personally couldn't reproduce it and suspected that it's got something to do with that specific hardware, OS or who knows what else..
I think user configuration is probably the cause. I think you should codesign the binary as well as the dmg as this can cause messages like "The app is damaged you should put it in the trash..." codesign --entitlements entitlements.plist --timestamp --options runtime --force --sign <apple.dev.id> binaryfile entitlements.plist file: <?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.disable-executable-page-protection</key> <true/> <key>com.apple.security.cs.disable-library-validation</key> <true/> <key>com.apple.security.cs.allow-dyld-environment-variables</key> <true/> </dict> </plist>
(In reply to Phil Beauvoir from comment #16) > I think user configuration is probably the cause. > > I think you should codesign the binary as well as the dmg as this can cause > messages like "The app is damaged you should put it in the trash..." > > codesign --entitlements entitlements.plist --timestamp --options runtime > --force --sign <apple.dev.id> binaryfile > > entitlements.plist file: > > <?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.disable-executable-page-protection</key> > <true/> > <key>com.apple.security.cs.disable-library-validation</key> > <true/> > <key>com.apple.security.cs.allow-dyld-environment-variables</key> > <true/> > </dict> > </plist> Thank you for all the input, Phil! I will reach back to the end user and see if we can gather more info on this.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
