eclipse-platform
Registering Link Handlers on Signed macOS Eclipse Installation breaks Eclipse Installation
Let's make sure issue is not already fixed in latest builds first.
- [x] I verified I can reproduce this issue against latest Integration Build of Eclipse SDK
Steps to reproduce
- On a fresh installation of macOS download and of the Eclipse EPPs that is signed and start it.
- On start up a job is running that registers this running Eclipse installation to handle the URI scheme "eclipse+command".
- This registration includes changing the info.plist file inside the Eclipse.app bundle (directory). This breaks the code signature of the Eclipse.app bundle.
- Close Eclipse
- Reboot your mac
- Try to start Eclipse again. This fails because the code signature is broken.
Tested under this environment:
- OS & version: macOS Sonoma 14.5 (23F79)
Community
- [x] I understand reporting an issue to this OSS project does not mandate anyone to fix it. Other contributors may consider the issue, or not, at their own convenience. The most efficient way to get it fixed is that I fix it myself and contribute it back as a good quality patch to the project.
I propose the following fix.
Only allow registration of new uri schemes if the running application is not signed. To allow to use link handlers on macOS the info.plist file must already contain the needed uri schemes when building the application so that these additional lines are taken into account when signing it.
I will provide a PR shortly.
How do things work when one "installs" a dozen or more Eclipse IDE's? I expect the installer is similarly affected, but folks often just throw it away after using it...
How do things work when one "installs" a dozen or more Eclipse IDE's? I expect the installer is similarly affected, but folks often just throw it away after using it...
I think the installer creates unsigned installations so they are not affected by this. The installer itself should be affected as well. To solve this the installer should already write it's uri scheme into its info.plist at build-time.
@soethoff or @sratz: Can you provide more details?
Yes, I expect the installer creates unsigned installation. The installer is a signed and notarized application on macos so will be affected:
Of course all the EPP IDE packages, and all downstream products will be affected if they are making use of this feature, so the build-time impact needs to be understood.
While I do not think folks will have a bunch of installers laying around, I do expect some folks may well have a bunch of Eclipse IDEs laying around so I do wonder how that works. Which one is launched? How is the user prompted? Is the user always prompted?
Which one is launched? How is the user prompted? Is the user always prompted?
Only one app can handle a scheme. macOS does not prompt the use at all but "randomly" selects one (if there are multiple). This is really bad what has always been the case anyhow.
This issue (and the linked PR) is about the really sever issue that registering a scheme at runtime will basically render your eclipse installation useless.
I think the installer creates unsigned installations so they are not affected by this. The installer itself should be affected as well. To solve this the installer should already write it's uri scheme into its info.plist at build-time.
Exactly, the unsigned installations created by the installer are fine, but the installer itself is broken after first use. To use the installer again you either need to do a local codesign or re-download it. The 'second' installer will work without further issues, since the URI scheme is already assigned to the 'first' installer and even after deleting the 'first' one, the entry in the system preferences will stay until a (manually) clean-up is done. Unfortunately I'm currently not sure, if there is a specific event, which triggers the clean-up. I'm only able to the clean-up manually using terminal commands.
While I do not think folks will have a bunch of installers laying around, I do expect some folks may well have a bunch of Eclipse IDEs laying around so I do wonder how that works. Which one is launched? How is the user prompted? Is the user always prompted?
I wasn't able to find much information from Apple how such a situation will / should be handled. What I found is the documentation about the Launch Services - Launch Services Programming Guide. From my perspective there are two points quite interesting (Section - Preferred Application for a URL):
'If the user has specified an explicit binding for the URL (or for the entire URL type to which it belongs), the preferred application is the one the user has specified.'
My understanding would be, that it should be somehow possible to specify a preferred application, but nevertheless it would be necessary that every application has the URI scheme as part of the Info.plist. Dynamically changing the file is not possible, since it will break the signature (current behaviour). Maybe someone in the community knows a bit more about this and can provide some more background information. My assumption is, if this is still possible (the documentation got the last update 2013), this has to be handled by the application itself by calling a specific API.
'If two or more candidate applications remain after all of the foregoing criteria have been applied, Launch Services chooses one of the remaining applications in an unspecified manner.'
I think this is exactly what @BeckerWdf relates to. As a comparison I tested this behaviour using VS Code (they provide the 'vscode://' URI Scheme). I created an HTML page, clicked the link and randomly one version on my VM got opened. No information, no user prompt, nothing. For me this looks like Apples strategy, that there always should be only one installation of an application available. VS Code is following this approach and doesn't allow to run two instances of VS Code at the same time.
Overall I think this issue and PR will really help us improving the overall experience of Eclipse on macOS. Currently the first contact will automatically lead to a broken installation, loosing settings, configurations, etc. Even if we allow in this case only one instance to be available as link handler for the 'eclipse+command' URI scheme, we will definitely improve the experience. So just for reference, here are some links to reports of the issue without a real solution and explanation of the root cause:
- https://www.eclipse.org/forums/index.php/t/1111528/
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=578883
- https://stackoverflow.com/questions/70725347/the-application-eclipse-can-t-be-opened-macos-monterey
- https://www.youtube.com/watch?v=jUgD6r51HCk (YouTube Tutorial - Explaining workaround)
- https://forums.developer.apple.com/forums/thread/684509
I have provided two pull requests in P2 and PDE which allows to configure <CFBundleURLTypes> entries in the macOS app bundle Info.plist file via *.product definitions:
https://github.com/eclipse-equinox/p2/pull/533
https://github.com/eclipse-pde/eclipse.pde/pull/1326
We still need to pre-register the default themes via the new IMacOsBundleUrlType API in the .product files for the several packages:
eclipse+commandin the Eclipse SDK + runtime binary + all the EPP packageseclipse+marketplacein the EPP packageseclipse+installerin the Oomph installer We will provide pull-request for those soon, referencing this issue, but since the breakage of the app bundle is fixed we can keep this one closed.
