| Summary: | org.eclipse.equinox.launcher_1.0.101.R34x_v20080819.jar fails to web-start with java 7 u 45 | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Anil Kondichetty <konan03> |
| Component: | Launcher | Assignee: | Project Inbox <equinox.launcher-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | daniel_megert, dave.nice, david_williams, pascal, pawel, peleg.yiftachel, strider80, tjwatson |
| Version: | 3.4 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | stalebug | ||
| Bug Depends on: | |||
| Bug Blocks: | 416870 | ||
|
Description
Anil Kondichetty
The same is applicable for the below plugins as well. org.eclipse.core.contenttype_3.3.0.v20080604-1400.jar org.eclipse.core.jobs_3.4.0.v20080512.jar org.eclipse.core.runtime_3.4.0.v20080512.jar org.eclipse.core.runtime.compatibility.auth_3.2.100.v20070502.jar org.eclipse.equinox.app_1.1.0.v20080421-2006.jar org.eclipse.equinox.preferences_3.2.201.R34x_v20080709.jar org.eclipse.equinox.registry_3.4.0.v20080516-0950.jar org.eclipse.equinox.launcher_1.0.101.R34x_v20080819.jar org.eclipse.equinox.common_3.4.0.v20080421-2006.jar org.eclipse.update.configurator_3.2.201.R34x_v20080819.jar org.eclipse.osgi_3.4.2.R34x_v20080826-1230.jar I am having similar issues (using org.eclipse.equinox.launcher_1.2.0.v20110502.jar) See e.g. this on how to resolve http://www.eclipse.org/forums/index.php/t/552636/ It seems there are at least two issues: - as a new security measure, Oracle decided that properties in the jnlp file are ignored unless they are prepended with "jnlp."... - the jars require extra security attributes in the manifest (as described here http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html) I also get these messages too on the launcher so I am not sure if all of jars need these attributes. This means that the PDE feature export wizard for webstart is now broken. (http://help.eclipse.org/indigo/index.jsp? topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fjava_web_start.htm ) Perhaps the wizard can be adjusted to add the required manifest entries? Note that I worked around this issue by editing the manifest.mf in the equinox launcher jar. I changed the plugin name to add "patched" and added: Permissions: all-permissions Codebase: * Application-Name: <my application name> Trusted-Only: true Trusted-Library: true Do all jars need to contain these entries? (In reply to Pascal Rapicault from comment #4) > Do all jars need to contain these entries? I am actually still struggling with getting a simple RCP webstart application to work. I think the answer is unfortunately YES and it is not sufficient to do this only in the equinox launcher jar what I have done. I think what I am seeing are classloading problems. This is consistent with what is explained here: https://blogs.oracle.com/java-platform-group/entry/new_security_requirements_for_rias It seems that code that is running with all-permissions requires the manifest of each jar to have the security entries. This post also says you need to do this for each jar: http://stackoverflow.com/questions/19407102/java-7-update-45-broke-my-web-start-swt-application This post shows how it may be done by using Ant: http://www.eclipse.org/forums/index.php/t/552636/ Note that I'm not sure if "Trusted-Only" is actually required or a good idea to include. I think the solution to this would be to change the PDE export wizard to add the extra security entries to the manifest jars before signing them. Accidentally used a blog link. The link I intended was http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html It explains that classes can't be loaded unless they use the security manifest entries. It's also recommended to add a timestamp when using the jarsigner. "No -tsa or -tsacert is provided and this jar is not timestamped. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2016-02-17) or after any future revocation date.") Thanks for the details. I don't have much free time available to address this. But if you are interested you can provide a patch for PDE Build and I can review it. The code is located in http://git.eclipse.org/c/pde/eclipse.pde.build.git/tree/org.eclipse.pde.build but I don't remember the details of which class exactly. That said I assume that you should be able to find that quickly. Also, one of the blog post mentions a change in the launcher code and it would be good to have that fixed directly in Eclipse as well. (In reply to Pascal Rapicault from comment #9) > .. > > Also, one of the blog post mentions a change in the launcher code and it > would be good to have that fixed directly in Eclipse as well. Yes, I also had to create a custom launcher to fix the mentioned parameter passing issue. Hello, Does anyone know if there is any plan for fixing this issue so that no workaround will be needed ? If yes, in which update of Java 7 does Oracle plan to fix it ? (In reply to Peleg Yiftachel from comment #11) > Hello, > Does anyone know if there is any plan for fixing this issue so that no > workaround will be needed ? If yes, in which update of Java 7 does Oracle > plan to fix it ? Oracle has tightened the security requirements for webstart applications. This is a feature not a bug, so I don't expect Oracle will revert this change. The problem is that at the time the Eclipse Webstart launcher was created the new security manifest entries were not required. I am an Eclipse user not a committer so I have no idea if or when this will be fixed. There is not a lot of people working in this space, so you have two possibilities: 1 - Even though you are not a committer, you can provide a patch and it will get reviewed and integrated. You can find the code in the following git repo http://git.eclipse.org/c/equinox/rt.equinox.framework.git and more precisely the file of interest is http://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/bundles/org.eclipse.equinox.launcher/src/org/eclipse/equinox/launcher/WebStartMain.java 2 - Find someone who is willing to get paid to fix this issue. Same would go about the PDE side added "web-start" to title, since I found it confusing since sounded to be so general that launcher would never start. (which, I just tested, and started fine for me .. but .. that was before I read bug closely). I do think equinox team should immediately make fix to not swallow "security exceptions" (which, I assume was the the one mentioned in http://www.eclipse.org/forums/index.php/t/552636/ Other than that, I think to fix this properly will take some specialized knowledge of "web apps" and the changes Oracle has made. In particular, I found some of the comments in the forum on "how to work around" current issues, to be disconcerting that "permissions=all" had to be used ... which sort of seems to defeat the purpose of the attempt to improve security (and from what I can tell in comments of WebStartMain.java this may have always been true ... but, ... if that's true, then if there is anyway to improve on that, that'd be nice). And, should mention ... I know very little about this area ... so could easily be mis-interpreting some of the comments, which I've only skim read. But ... swallowing exceptions is almost ever the right thing to do ... and would not take much to fix. At least then, developers of "webstart apps" would get a hint of what problem was). I need to make it clear to the community. There is no current committer that has the expertise, let alone resources to address this bug. The current jnlp support is pretty brittle because of the way it tries to discover bundles included on the jnlp class loader class path. We have had to work around other security issues in the past that had been "fixed" in newer java releases (see bug 240500). That bug may give some insight to a solution here. In the end, I am not convinced having the bundle jars included on the jnlp class loader is the correct approach. I'm not experienced with jnlp so I don't know if this is possible, but an approach that somehow made the bundles jars available as resources instead of entries on the jnlp class loader would help. Then our launcher could stage the bundles properly (into a plugins/ type folder) and then we could launch more "normally" like we do for typical RCP applications. 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. |