Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 370237

Summary:	Error essage due to "o.e.core.runtime.compatibility.auth not installed" when connecting on Eclipse 4.2m5
Product:	[Tools] Target Management	Reporter:	Martin Oberhuber <mober.at+eclipse>
Component:	RSE	Assignee:	dsdp.tm.rse-inbox <tm.rse-inbox>
Status:	NEW ---	QA Contact:	Martin Oberhuber <mober.at+eclipse>
Severity:	major
Priority:	P3	CC:	ddykstal.eclipse, dmcknigh, dominik.stadler
Version:	3.4
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
Whiteboard:
Bug Depends on:	225320
Bug Blocks:

Description Martin Oberhuber

2012-01-31 11:14:36 EST

Build ID: RSE 3.4m5

When running on Eclipse 4.2m5, as soon as I make a connection in RSE, I see following message and stacktrace printed ... it looks like storing passwords is not possible out of the box in 4.2 any more.

This must be considered a major issue for Juno since 4.2 is the designated release train version. Plus, the core.runtime.compatibility.auth bundle is not available on the Eclipse Platform 4.2 p2 repository so end users won't get it easily.


!ENTRY org.eclipse.core.runtime 2 0 2012-01-31 17:05:51.738
!MESSAGE Authorization infrastructure (org.eclipse.core.runtime.compatibility.auth) not installed.
!STACK 0
java.lang.ClassNotFoundException: org.eclipse.core.internal.runtime.auth.AuthorizationDatabase
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:169)
	at org.eclipse.core.internal.runtime.AuthorizationHandler.getAuthClass(AuthorizationHandler.java:51)
	at org.eclipse.core.internal.runtime.AuthorizationHandler.loadKeyring(AuthorizationHandler.java:72)
	at org.eclipse.core.internal.runtime.AuthorizationHandler.getAuthorizationInfo(AuthorizationHandler.java:265)
	at org.eclipse.core.runtime.Platform.getAuthorizationInfo(Platform.java:621)
	at org.eclipse.rse.core.PasswordPersistenceManager.getPasswordMap(PasswordPersistenceManager.java:340)
	at org.eclipse.rse.core.PasswordPersistenceManager.find(PasswordPersistenceManager.java:518)
	at org.eclipse.rse.core.PasswordPersistenceManager.find(PasswordPersistenceManager.java:398)
	at org.eclipse.rse.core.PasswordPersistenceManager.passwordExists(PasswordPersistenceManager.java:262)
	at org.eclipse.rse.core.PasswordPersistenceManager.passwordExists(PasswordPersistenceManager.java:247)
	at org.eclipse.rse.core.subsystems.AuthenticatingConnectorService.hasPassword(AuthenticatingConnectorService.java:115)
	at org.eclipse.rse.internal.ui.actions.SystemClearPasswordAction.checkObjectType(SystemClearPasswordAction.java:64)
	at org.eclipse.rse.ui.actions.SystemBaseAction.updateSelection(SystemBaseAction.java:535)
	at org.eclipse.rse.ui.actions.SystemBaseAction.setSelection(SystemBaseAction.java:449)
	at org.eclipse.rse.ui.actions.SystemBaseAction.setInputs(SystemBaseAction.java:358)
	at org.eclipse.rse.internal.ui.view.SystemView.fillContextMenu(SystemView.java:1144)
	at org.eclipse.rse.internal.ui.view.SystemView.menuAboutToShow(SystemView.java:1167)
	at org.eclipse.jface.action.MenuManager.fireAboutToShow(MenuManager.java:342)
	at org.eclipse.jface.action.MenuManager.handleAboutToShow(MenuManager.java:473)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.e4.ui.workbench.renderers.swt.MenuManagerRendererFilter.showMenu(MenuManagerRendererFilter.java:253)
	at org.eclipse.e4.ui.workbench.renderers.swt.MenuManagerRendererFilter.handleShow(MenuManagerRendererFilter.java:225)

Comment 1 Martin Oberhuber

2012-01-31 12:21:37 EST

When Eclipse Platform first started building the 4.x SDK, they omitted any compatibility code that supported migration from 2.1 to 3.0, as long as it didn't remove any API. Supporting migration from 2.x directly to 4.x seemed like overkill. We've done similar things in the 3.x stream, such as removing org.eclipse.core.resources.compatibility at some point (bug 336129). 

The old API for passwords has been deprecated for many years, replaced with Equinox secure storage. The old API has long been a source of problems for people because it includes cryptographic code (bug 121997). It is also inherently insecure because it relies on the user setting a password on the command line, which nobody ever does. 

If somebody really wants the old implementation, they can add the fragment back. It's available in the 3.8 p2 repository. The old API hasn't actually been deleted in this case, but I think it probably should be (bug 370248). Migration docs will be written for this in 4.2 (bug 370247). 

Looks like in TM, we should look at adopting Equinox secure storage, though we'll probably need to consider migration of old workspaces with saved passwords too. Bug 225320 is open for migrating TM to Equinox Secure Storage.