Community
Participate
Working Groups
The codesignging on OSX is severly broken: The Eclipse.app does contain folders which are modified, and this is un-acceptable: i.e. it goes against the spirit of code-signing: only immuteable atrefacts can be signed. background (OS X Code Signing In Depth): https://developer.apple.com/library/mac/technotes/tn2206/_index.html Problem #1: the configuration folder in inside the signed app I download the Eclipse app (I'm using OSX 10.11.4): eclipse-jee-mars-2-macosx-cocoa-x86_64.tar.gz I expand and check the signature: (check is OK) fishstatj:~ bergert$ spctl -a -v --raw /Users/bergert/Desktop/Eclipse.app /Users/bergert/Desktop/Eclipse.app: accepted <?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>assessment:authority</key> <dict> <key>assessment:authority:row</key> <integer>6</integer> <key>assessment:authority:source</key> <string>Developer ID</string> </dict> <key>assessment:remote</key> <true/> <key>assessment:verdict</key> <true/> </dict> </plist> then I run Eclipse.app; when it asks to open a workspace I cancel; quit the app. Launching Eclipse, creates files and folders inside the signed Eclipse.app bundle: /Contents/Eclipse/configuration Then I check the signature again, and it is broken: fishstatj:~ bergert$ spctl -a -v --raw /Users/bergert/Desktop/Eclipse.app /Users/bergert/Desktop/Eclipse.app: a sealed resource is missing or invalid. Problem #2: the plugins and dropins folders are inside the signed app This means, I cannot add my favourtie plugin, or even run an Eclipse update, without invalidating the app signature ! Solution: The whole Eclipse folder must be located outside the app. The best solution would be to go back to having these files in the same folder as the Eclipse app; because: I have more than version of Eclipse installed - and using some common directory (AppData?) would make it impossible to have several versions of Eclipse on one computer. Background: https://bugs.eclipse.org/bugs/show_bug.cgi?id=461725 (the problem was created here) https://bugs.eclipse.org/bugs/show_bug.cgi?id=461728 (and perpetuated here) https://bugs.eclipse.org/bugs/show_bug.cgi?id=445108 (code-signing 10.11) https://bugs.eclipse.org/bugs/show_bug.cgi?id=482454 (better support for 10.11) https://bugs.eclipse.org/bugs/show_bug.cgi?id=432932 (packaging)
In order to properly guarantee Eclipse behavior on macOS we must provide an Eclipse.app bundle that *never* modify itself. This means that: - Equinox osgi.install.area is moved out of Eclipse.app bundle - Support for `dropins` is removed from Eclipse.app bundle - Plugins and features are written outside of Eclipse.app bundle BTW, here is some feedback from Apple (https://forums.developer.apple.com/thread/115425): > Self-modifying apps have been unsupported on the Mac since… well… forever. > macOS’s increasingly stringent code signing rules are just the latest in a > long line of problems that self-modifying apps have encountered over the > years [2]. It’s hard to predict the future with 100% accuracy, but I’m > quite confident that these problems are going to get worse over time.
Agree: the application can never* modifies itself. Suggestion: 1) Application which never modifies itself (is replaced when updated) 2) plugins, features, logs, p2 and configuration saved to some temp location (into current user dir) For my own RCP application, I have patched the macOS platform launcher: at startup it copies the configuration folder from within the signed application bundle into the user directory. My RCP plugins and features are within the singed bundle, because users do not need to update these. Users receive updated plugins when they install a new version of the app. My application is code-signed; signature remains intact after launch. Apple's current codesign utility creates fingerprints for all additional files in the app bundle which are Eclipse configuration and Eclipse plugins/features.
I wonder if mac supports read-only shared installations? Windows and Linux definitely support that. Making the installation read-only prevents it from being modified; on the other platforms, a "surrogate" installation/configuration is automatically created in the ~/.eclipse folder to support that use case.
(In reply to Ed Merks from comment #3) > I wonder if mac supports read-only shared installations? Windows and Linux > definitely support that. Making the installation read-only prevents it from > being modified; on the other platforms, a "surrogate" > installation/configuration is automatically created in the ~/.eclipse folder > to support that use case. I experimented with it a few years ago. As far as I remember I still found issues with some things being written into the .app bundle. The main problem with an "~/.eclipse" folder is that it conflicts with multiple .app bundles on the system. There is a way to create unique folders and set an attributes on the .app bundle to remember the folder. However, that never was cleaned up properly. I wonder if there is an alternate/better strategy. Instead of trying to fix Eclipse (which likely will be too much work) what if there would be a small bootstrap app that takes care of installing and launching Eclipse from the proper "~/Library/Application Support/Eclipse" location? Can the installer be this app?
Note that I recently fixed tests that test read-only installations. Those used to run only on Windows (and always fail) but now run successfully on the Windows, Linux and Mac. So it seems to me that if recursively every file and folder in the *.app folder (except perhaps the info.plist?) were read-only that it's of course not possible for the files to change, and it seems likely to me that this would work fine, but if not that certainly needs to be fixed. Because it works fine on other platforms I imagine it should just work. Also p2 will generate unique surrogates in the ~/.eclipse folder; that does that properly today for Linux and Windows. So someone with a vested interest ought to try that all out. For me working on a virtual box with an older OS version of Mac is a nightmare.
IMHO there are two use cases: 1) I distribute my RCP application. In this case read-only is not an issue, is desired in fact; as the user does not need to update or add plugins. If the user wants to update, he will download a new version of the entire app. And starting with macOS 10.14 the /Applications folder is on a read-only system volume in any case. 2) For distributing Eclipse as an IDE read-only is a no-go proposition. How can I add my WindowBuilder plugins, the Babel plugins, or Lint plugins? I need to update plugins, and (IMHO) the best solution would be to move the plugin folder outside of the signed (and read-only) App bundle. At the end of the day, only the platform launcher needs to be signed, for plugins better use the Eclipse/Java signing-secturity. A possible Solution: I am delivering my RCP app as a signed bundle, with the Configuration inside the app bundle. At startup, my patched platform launcher, copies the Eclipse/Configuration folder from inside the App bundle to the /Users folder (~/myApp/Configuration). And yes, the same needs to be done for plugins folder (but plugins in my case I don't update). In my tycho build, I just replace the platform launcher with my patched one, and in the app.product I have a custom launching agrgument (obviously only for tycho-build, for launch from inside Eclipse I use another app.launch configuration file). app.product/Launching/Launching Arguments/macosx/Program Arguments: -configuration @user.home/fishstatj_workspace/configuration This is used in my RCP application with 2000 macOS downloads every year: https://github.com/bergertom/rt.equinox.framework.git only 2 changes library/cocoa/eclipseCocoaCommon.c library/eclipseMain.c
(In reply to Thomas Berger from comment #6) > IMHO there are two use cases: > 1) I distribute my RCP application. In this case read-only is not an issue, > is desired in fact; as the user does not need to update or add plugins. If > the user wants to update, he will download a new version of the entire app. > And starting with macOS 10.14 the /Applications folder is on a read-only > system volume in any case. > So that's good. > 2) For distributing Eclipse as an IDE read-only is a no-go proposition. How > can I add my WindowBuilder plugins, the Babel plugins, or Lint plugins? I > need to update plugins, and (IMHO) the best solution would be to move the > plugin folder outside of the signed (and read-only) App bundle. At the end > of the day, only the platform launcher needs to be signed, for plugins > better use the Eclipse/Java signing-secturity. > This does work though A surrogate is created and the user can install into that surrogate. > A possible Solution: > I am delivering my RCP app as a signed bundle, with the Configuration inside > the app bundle. At startup, my patched platform launcher, copies the > Eclipse/Configuration folder from inside the App bundle to the /Users folder > (~/myApp/Configuration). And yes, the same needs to be done for plugins > folder (but plugins in my case I don't update). In my tycho build, I just > replace the platform launcher with my patched one, and in the app.product I > have a custom launching agrgument (obviously only for tycho-build, for > launch from inside Eclipse I use another app.launch configuration file). > app.product/Launching/Launching Arguments/macosx/Program Arguments: > -configuration @user.home/fishstatj_workspace/configuration > Any layout changes will have a major impact. E.g., can one update a version installed with the old layout to one that that expects a new layout? How is the Eclipse Installer impacted? > This is used in my RCP application with 2000 macOS downloads every year: > https://github.com/bergertom/rt.equinox.framework.git > only 2 changes > library/cocoa/eclipseCocoaCommon.c > library/eclipseMain.c Coordinately with the launcher is another impact. I'm not saying this is impossible or even a bad idea. But it's a very large time investment with far reaching impact. Realistically there is no resource to deal with that. I've changed the severity because this does not block you. A more appropriate severity would be enhancement because the current design is working as designed, however questionable that design may be. But I don't want you to take offense because you do raise valid reasons why an alternative design might well be better.
(In reply to Thomas Berger from comment #6) > IMHO there are two use cases: > 1) I distribute my RCP application. In this case read-only is not an issue, > is desired in fact; as the user does not need to update or add plugins. If > the user wants to update, he will download a new version of the entire app. > And starting with macOS 10.14 the /Applications folder is on a read-only > system volume in any case. I this case I would probably create an RCP app without any p2 plugins. Probably even org.eclipse.equinox.simpleconfigurator should be dropped and start levels can be hard coded in the product file. > the app bundle. At startup, my patched platform launcher, copies the > Eclipse/Configuration folder from inside the App bundle to the /Users folder > (~/myApp/Configuration). And yes, the same needs to be done for plugins > folder (but plugins in my case I don't update). I'm not sure that's necessary. Back when I experimented with it, I had the following in my product file: <property name="osgi.instance.area.default" value="@user.home/Library/Application Support/My IDE/workspace" os="macosx" /> <property name="osgi.configuration.area.default" value="@user.home/Library/Application Support/My IDE/configuration" os="macosx" /> <property name="osgi.install.area.readOnly" value="true" os="macosx" /> But this was an IDE (including p2 and simpleconfigurato) and I remember there were still writes into the .app bundle. I wasn't able to disable them completely. Maybe it was this one: https://bugs.eclipse.org/bugs/show_bug.cgi?id=431116#c47
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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.
This is still a problem with latest Eclipse versions, reopening.
With macOS Sonoma, the previously possible workaround to remove the signature (codesign --remove Eclipse.app" for the Eclipse.app folder no longer works. The app MUST be signed to start, otherwise the attempt to start "eclipse" ends with "Killed 9" from the OS. As a result it is not possible really use Eclipse anymore under macOS because everything from the .ini files, the logs to the contents of the "Eclipse" subfolder is subject to changes during usage. A a result the signure breaks and the app cannot start the next time at all.
