Community
Participate
Working Groups
Build ID: 3.2.2 Steps To Reproduce: It looks like the the CVS plug-in org.eclipse.team.cvs.core provides an authenticator extension which the org.eclipse.team.cvs.ui plug-in uses (via it's extension point) to use the org.eclipse.team.internal.ccvs.ui.WorkbenchUserAuthenticator class as the UI authenticator class when connecting to CVS We (a product building on Eclipse) provide an Ant task which does the equivalent of File > Import > Team Project Set to import a PSF file into the workspace. For CVS, if a user has authentication enabled and imports a PSF file that was built using their CVS-controlled projects then we are unable to connect to CVS to checkout the files. This is because there is no headless CVS authenticator (only a UI authenticator exists). To work-around this we embed the userid and password that the customer specifies in their Ant script into the repository reference, i.e. <project reference="1.0,:pserver:dev.eclipse.org:/cvsroot/webtools,servertools/plugins/org.eclipse.wst.server.core,org.eclipse.wst.server.core,R1_5_5_patches"/> would become (for example): <project reference="1.0,:pserver:sample_user:sample_password@dev.eclipse.org:/cvsroot/webtools,servertools/plugins/org.eclipse.wst.server.core,org.eclipse.wst.server.core,R1_5_5_patches"/> This works great, except that the userid and password are written in plain text to the .metadata\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.team.cvs.core.prefs file which exposes security concerns. Two questions: 1) Is there a way that we could change this so the org.eclipse.team.cvs.core.prefs file does not contain the userid/password? 2) I tried implementing my own authenticator extension point, but for some reason the logic to pick the authenticator was set to take the 1st authenticator found, (look at org.eclipse.team.internal.ccvs.core.connection.CVSRepositoryLocation#getPluggedInAuthenticator()) and for me it's picking the authenticator in the team.cvs.ui plug-in. Can this logic be changed so that it always picks the authenticator that I want? More information: I am marking this as major as this is a security concern within our product.
Regarding question 2) please take a look at bug 204548 where Michael explains briefly how and why the authenticator extension point works.
Ignore comment 1 as it refers to a different authenticator. If you are trying to import headless, the best way to accomplish what you want is to remove the CVS/UI plug-in from your install. You can then register your own authenticator which should get picked up since the UI authenticator would no longer be available.
Michael has provided a work-around where we are able to setup the CVS repository before doing the project set import. This is a reasonable work-around however the better long-term solution would be to allow us to implement our own headless CVS authenticator. Given that this would be a feature enhancement I am changing the severity to 'enhancement'. Thanks Michael for the work-around that we can use for now: boolean isKnown = KnownRepositories.getInstance().isKnownRepository(repositoryLocationWithUserId); CVSRepositoryLocation location = null; try { location = (CVSRepositoryLocation) KnownRepositories.getInstance().getRepository(repositoryLocationWithUserId); } catch (CVSException cvsEx) { ... } if (!isKnown) { location = (CVSRepositoryLocation) KnownRepositories.getInstance().addRepository(location, false); } location.setPassword("password"); location.updateCache();
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.
