Community
Participate
Working Groups
Please can support for SSPI (Windows-specific) and gserver (UNIX + Kerberos equivalent) protocols be added, to facilitate integration with CVSNT? NetBeans handles this by allowing the user to specify a different CVS binary and talking to that, rather than using the built-in CVS client; maybe this is easier. Jon.
From mailing list posting by Rolf Wilms..... There is an implementation of the sserver protocol for both CVS and CVSNT available here: http://home.arcor.de/rolf_wilms/cvsssl/cvsssl_help.html Like sspi, sserver supports encrypted connections but uses SSL rather than sspi. The benefit is that it also works with non-Windows clients. The drawback is that it does not support single sign-on. Please note that the current implementation of that plugin does not work with M6. M5 has been reported to work. Regards, Rolf
*** Bug 51120 has been marked as a duplicate of this bug. ***
I got bored and frustrated enough one day to write a SSPI plug-in for Eclipse CVS. The company I work for decide to use CVSNT with SSPI authentication, and are still having meetings on whether or not to enable PServer so that non-windows clients and IDEs that don't support SSPI can use the archive. Anyway, to make a long story short, here is the source. I don't want to maintain it so I am giving it up to the masses. It uses code from the CVSNT code base so it has to be GPL (I know, I don't like GPL either). It wouldn't be too hard to re-write the whole thing from scratch to lose the GPL virus, I just don't have time. http://www.pogozone.net/projects/sspi-plugin-source.zip -- Jacob S. Barrett jbarrett@amduat.net www.amduat.net
has anyone successfully compiled the sample code from Jacob Barrett under vc++ 6?
Created attachment 14718 [details] Modified version of Jacob Barret. It now compiles in VC++6 and does not require VC++ 7 This is modified copy of Sspi plugin from Jacob S. Barrett jbarrett@amduat.net www.amduat.net found at http://www.pogozone.net/projects/sspi-plugin-source.zip This version will compile under VC++6. More details are in the readme.txt inside the zip file.
The last plug in did not work for me at all. However, this http://www.cvsnt.org/pipermail/cvsnt/2005-September/020966.html post to the CVSNT list was extremely helpful to me. I encountered a few problems, but did figure them out and I posted them as a reply to the above message. I hope this helps other people. Joelle
Created attachment 34168 [details] 100% Java plugin that allows GSSAPI access via GServer for any OS with Java 1.4 I've written a fragment to the existng 3.1 CVS server that uses GSSAPI to authenticate against the remote CVS server using the :gserver: protocol. This should be adaptable to any GSSAPI protocol, but at present, it assumes the use of kerberos to perform the authentication. This has been tested on Mac OS X 10.4 as client, and 10.4 Server as the server. I'll report as I find out it works on other combinations. You need to ensure that you run 'kinit' to obtain a Kerberos Ticket Granting Ticket (TGT) before you try to run the CVS :gserver: operations. Otherwise, it hangs (actually, it's asking for your userid/password from the console, but that doesn't work for obvious reasons). This will only work on systems that meet: Eclipse 3.1 Kerberos V5 KDC already configured for the OS you're using Java 1.4 There's a README.TXT file in the plugin (which can be dropped straight in; it also contains the source as well if you want to investigate/extend/play around with it I plan to make updates to this to make it production ready; at present, it's alpha stage. That is, I've checked stuff in and out with it already, but it's not as foolproof as it could be. Note that there are some setup required on the KDC: cvs/my.host.name needs to be created as a principal (and exported to the keytab where the CVS server can find it) There may be some encryption methods needed to be set up on the server (documented in README.TXT) In short, don't try this unless you already have a working CVS server that supports :gserver:, and you're able to run a cvs -d :gserver:some.host.name/some/root/name checkout someproject. Please Cc feedback/reports to this bug, or to my mail address. I'll improve this and put a new version up at a later stage. Given that it's only really 2 files, I don't see an issue in uploading the plugin that you can just drop into the plugins directory, but if anyone objects I'll stop doing that. Alex.
I've created a new attachment which has a plugin for :gserver: support. It's written in pure Java, and uses libraries in Java 1.4 to perform authentication against system credentials. There's a readme file (and source) in the plugin itself, but you should just be able to drop it into a plugins/ directory to get it to work. Note that you must run kinit to obtain credentials first; it ignores whatever userid/password you put in. This has only been tested on Mac OS X, so I'd be interested if anyone can get it to work on other systems. There are some known issues in the README.TXT file in the jar with some debugging steps if it doesn't work. Please leave feedback on this bug and I'll pick it up and try to improve the next version. Hopefully if it works well enough and I can tidy it up, it can be adopted in the 3.2 stream; there's some refactoring that could be done with the existing PServer classes, and I'm happy to volunteer to do that; but I want to ensure that we iron out all the bugs before doing the refactoring step :-) Alex.
Do you think it is possible to write the sspi authentication in pure Java?
The plugin that I've written (in 2006) is pure Java, if you're asking me. The plugin of 2004 isn't. If you're asking whether it could be re-implmented to do the authentication outside of the JAAS/GSSAPI framework built in to Java, I don't see why not, but I don't see the point either.
Alex, I was asking for sspi authentication, not gserver. Or could gserver be used also on Windows as a sspi alternative? Sorry, I'm not that familiar with these OS-specific authentication methods.
GSSAPI authentication is a generic form of authentication. It so happens that it can use Kerberos authentication, but it can handle other forms. SSPI is Microsoft's specific extensions to GSSAPI that are probably incompatible. However, if you're using an Active Directory setup to perform authentication, then essentially GSSAPI and SSPI are equivalent. Since SSPI is a native protocol to windows, it's got to have a native hook to call the Windows methods. However, the GSSAPI libraries on each platform integrate with credentials, so you might find that you can use the gserver mechanism instead of the SSPI one.
FYI I've tested this on a windows system, and it didn't find krb5.ini so gave up. It should be getting the info from the windows system rather than expecting to see a file, so I'll do some more digging and see if I can find out what's going wrong.
Trying on OSX 10.4 against a known gserver with kinit and got the following error any tips would be appreciated: !ENTRY org.eclipse.core.jobs 4 2 2006-04-21 20:49:38.804 !MESSAGE An internal error occurred during: "Fetching children of HEAD". !STACK 0 java.lang.SecurityException: Unable to locate a login configuration at com.sun.security.auth.login.ConfigFile.<init>(ConfigFile.java:97) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at java.lang.Class.newInstance0(Class.java:350) at java.lang.Class.newInstance(Class.java:303) at javax.security.auth.login.Configuration$3.run(Configuration.java:216) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.Configuration.getConfiguration(Configuration.java:210) at javax.security.auth.login.LoginContext$1.run(LoginContext.java:237) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.init(LoginContext.java:234) at javax.security.auth.login.LoginContext.<init>(LoginContext.java:403) at sun.security.jgss.LoginUtility.login(LoginUtility.java:72) at sun.security.jgss.krb5.Krb5Util.getTicketFromSubject(Krb5Util.java:137) at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331) at java.security.AccessController.doPrivileged(Native Method) at sun.security.jgss.krb5.Krb5InitCredential.getTgtFromSubject(Krb5InitCredential.java:328) at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:131) at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:72) at sun.security.jgss.GSSManagerImpl.getCredentialElement(GSSManagerImpl.java:149) at sun.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:389) at sun.security.jgss.GSSCredentialImpl.<init>(GSSCredentialImpl.java:60) at sun.security.jgss.GSSCredentialImpl.<init>(GSSCredentialImpl.java:37) at sun.security.jgss.GSSManagerImpl.createCredential(GSSManagerImpl.java:96) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:178) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:158) at org.eclipse.team.internal.ccvs.core.connection.GServerConnection.gssapiAuthenticate(GServerConnection.java:213) at org.eclipse.team.internal.ccvs.core.connection.GServerConnection.authenticate(GServerConnection.java:136) at org.eclipse.team.internal.ccvs.core.connection.GServerConnection.open(GServerConnection.java:99) at org.eclipse.team.internal.ccvs.core.connection.Connection.open(Connection.java:128) at org.eclipse.team.internal.ccvs.core.connection.CVSRepositoryLocation.createConnection(CVSRepositoryLocation.java:537) at org.eclipse.team.internal.ccvs.core.connection.CVSRepositoryLocation.openConnection(CVSRepositoryLocation.java:778) at org.eclipse.team.internal.ccvs.core.client.Session.open(Session.java:159) at org.eclipse.team.internal.ccvs.core.resources.RemoteFolderMemberFetcher.performUpdate(RemoteFolderMemberFetcher.java:97) at org.eclipse.team.internal.ccvs.ui.operations.FetchMembersOperation$InternalRemoteFolderMemberFetcher.performUpdate(FetchMembersOperation.java:69) at org.eclipse.team.internal.ccvs.core.resources.RemoteFolderMemberFetcher.fetchMembers(RemoteFolderMemberFetcher.java:64) at org.eclipse.team.internal.ccvs.core.resources.RemoteFolderMemberFetcher.fetchMembers(RemoteFolderMemberFetcher.java:55) at org.eclipse.team.internal.ccvs.ui.operations.FetchMembersOperation.execute(FetchMembersOperation.java:107) at org.eclipse.team.internal.ccvs.ui.operations.CVSOperation.run(CVSOperation.java:81) at org.eclipse.team.internal.ccvs.ui.model.CVSTagElement.fetchDeferredChildren(CVSTagElement.java:136) at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:207) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) Caused by: java.io.IOException: Unable to locate a login configuration at com.sun.security.auth.login.ConfigFile.init(ConfigFile.java:206) at com.sun.security.auth.login.ConfigFile.<init>(ConfigFile.java:95) ... 43 more
*** Bug 37414 has been marked as a duplicate of this bug. ***
I've updated the FAQ and CVS links page to point to the attachment. Moving to Later as there is no plan to address this further.
*** Bug 184114 has been marked as a duplicate of this bug. ***
I encountered some problems with this cvs sspi client. While trying to get some modules from a repository which path contains special characters ("é" in my case) on a cvs server running under windows (I don't know the version). Message got: > Could not connect to > :sspi:xxxx@xxxx:path\with\word_containing_é: > I/O exception occurred: Connection refused: > path\with\word_containing_�: no such repository > Connection refused: path\with\word_containing_�: no such repository I solved the problem by changing one line: in SSPIConnection.java: in method: private void authenticate() throws IOException, CVSAuthenticationException code: if (authenticateSSPI(in, out, line, user, password, domain, cvsroot.getHost())) { request = new StringBuffer(); request.append(cvsroot.getRootDirectory()); request.append(NEWLINE); // out.write(request.toString().getBytes("ASCII")); // replaced by the following line: out.write(request.toString().getBytes("ISO-8859-1")); out.flush(); line = readLine(in); } Maybe this can helps someone else...
Sadly, despite the patch being available for over two years, there's zero interest in the Team owners as actually addressing this bug (seeing as it's marked RESOLVED LATER, which is deprecated). As for accessing the data, the CVS protocol uses ASCII to do its resolution. It might be possible to default to the system charset, but I don't know whether that would work for all systems. Charsets outside of ASCII aren't really well treated in CVS.
Reopening.
I agree that this should not be RESOLVED LATER. I also agree that ideally this would be part of the Eclipse CVS plug-in. When I was an active committer on the CVS component, I didn't pursue getting this code in the repository because, based on the comments, it appeared to be incomplete (i.e. required running a separate utility to work and was only tested on Mac OS) and I was not convinced that there was a large enough demand for the feature to justify the amount of work it would take to make it real. If we want to move forward on this, it would be helpful to know what the current status of the plug-in is (i.e. does it work on Windows or Linux? Is it possible to get it to work without running an external utility?). The other issue is simply one of manpower. There has never really been more than one or two people on the Team/CVS/Compare component and there is currently only 1. It is difficult to justify the amount of work it would take to get this into the repository without knowing that it will have a significant impact. That is, if there are only a handful of users, it's not worth it but if there were 100s perhaps it could be justified. Given that this is a separate plug-in, one option would be to host the development of the plug-in elsewhere. This has the added advantage of giving those that have the necessary knowledge the ability to commit to the project. This would at least help contributions such as those from comment 18 to get included in the code base. This has been done in the past for extensions to the CVS plug-ins. I know this isn't ideal but it is better than the current state. And, if there was a large enough demand for the plug-in, the current CVS committer may consider accepting the contribution (but I'll let him comment on that).
Michael, Thanks very much for re-opening. In fact, work has gone on this plugin elsewhere and has been made to work under Eclipse 3.3 as well; the same could be done for 3.4. I have to touch base with those who made the changes, but it should be possible. The biggest problem with the CVS API is that it's pretty tightly coupled to itself. In the above patch (I think -- it's been a while since I wrote it), I separated out the superclass implementation of a generic CVS protocol with an abstract class, and provided an extension point by which CVS providers could be added. If I can supply this trivial refactoring as a standalone patch, it will make it much easier to develop the implementation separately and then add it as (e.g.) a fragment to the CVS bundle at a later stage. Right now, there's just a single CVS provider which makes it difficult to add new CVS authentication types at a later stage. Given that 3.4M6 has been and gone, isn't it too late for this in the 3.4 timeframe anyway? (Can we also bump the version up from 3.0 to 3.4 in the header?) Alex
Your comment is confusing to me. The CVS plug-in already has an extension point for connection methods. Are you talking about this or something else? If you mean somehting else and you have a patch, I'm happy to look at it.
It's been a while since I was in the details of this patch. However, I seem to recall that the UI is populated based on a list which was only known at bundle start, and thus adding other providers was nigh on impossible because a fragment couldn't add any plugin.xml entries, and you couldn't add a dependent bundle because the startup wouldn't notice. However, things may have changed or my recollection could be incorrect, so rather than hypothesising at this point I'll go back to the code and post an updated set of patches here and we can work from there. PS Thanks for updating for 3.4
A simple implementation of sspi support based on ext settings found here http://dev.eclipse.org/mhonarc/lists/platform-cvs-dev/msg00384.html Make sure that the command line cvsnt is working correctly with a cvsroot string like ":sspi:192.168.0.26:/cvs". On the client using Eclipse add the following to "C:\dev\vcs\cvsnt-2.5.03.2382\extnt.ini": [192.168.0.26] protocol=sspi hostname=192.168.0.26 directory=/cvs You are now ready to configure Eclipse: Windows => Preferences => Team => CVS => Ext Connection Method select "Use an external program to connect" CVS_RSH: C:\dev\vcs\cvsnt-2.5.03.2382\extnt.exe Parameters: {host} -l {user} -P {password} CVS_SERVER: cvsnt The sspi support is then possible with: public class SSPIConnectionMethod extends ExtConnectionMethod of which only the name is changed to sppi. Add this SSPIConnectionMethod to the plugin.xml and you're ready to go. Because I do not want to store my password I had to make a patch to CVSRepositoryLocation to promptForUserInfo when the password was null.
Created attachment 104094 [details] SSPIConnectionMethod class
Created attachment 104095 [details] plugin.xml SSPIConnectionMethod extension
Created attachment 104096 [details] CVSRepositoryLocation promptForUserInfo when the sspi password is null
Created attachment 104097 [details] SSPIConnectionMethod implementation
(In reply to comment #29) > Created an attachment (id=104097) [details] > SSPIConnectionMethod implementation > thanks for posting the attachments. excuse me for asking silly questions; but i'm not a plugin developer (just an eclipse user/java application programmer who would like to connect to an sspi authenticated cvsnt server; the alternative is to use the god-awful jDeveloper. bleah!). so it's not obvious to me what i need to do with the attachments you've posted (again, thanks for those). i think i've worked out what to do with the plugin.xml. but please, can you fill me in on what exactly to do with the SSPIConnectionMethod implementation (obviously it needs to be compiled; but then what?) and the "patch to CVSRepositoryLocation to promptForUserInfo"? for example: where do they go? my first guess is in the plugns directory. but can you confirm that? do i just put the bare SSPIConnectionMethod class file directly into the plugins directory? or do i add it to "org.eclipse.team.cvs.core_3.x.x.x.x..jar" where the ExtConnectionMethod class lives? your CVSRepositoryLocation looks like a copy & paste job. am i right? if so, i'm assuming i would need the source for CVSRepositoryLocation, then paste your patch into CVSRepositoryLocation and recompile? if that's the case, where do i get the source? please, fill me in? thanks in advance for your reply. and thanks again for posting the attachments.
Created attachment 104964 [details] Single patch file for SSPI support Forgot to change plugin.xml setting trace back to false. Will also be adding an instruction how to apply this patch in which one file is easier.
To roll your own patched plug-in jar read the following. Alternative if you're using the org.eclipse.team.cvs.core_3.3.2.r33x_....jar you could try the attached plug-in jar I created this way. I'm currently using eclipse-jee-europa-winter-win32.zip Version: 3.3.2 Build id: M20080221-1800 To apply patch the https://bugs.eclipse.org/bugs/attachment.cgi?id=104964 download it to for example D:\download Next open Eclipse and select File => Import => CVS => Projects from CVS => Next Create a new repository location (if it isn't already there) with: Host: dev.eclipse.org Repository path: /cvsroot/eclipse User: anonymous Connection type: pserver Click Next Select Use an existing module: org.eclipse.team.cvs.core and click Next Checkout as a project in the workspace Checkout subfolders Click Next Refresh Tags Select Branches +> R3_3_maintenance and click Finish After the import select Window => Open perspective => Java On org.eclipse.team.cvs.core right-click and select Team => Apply Patch... Find the downloaded File: D:\download\patch.txt and click Next and Finish Testing the patch is optional and can be done as follows: Just select Window => Open perspective => Java And open org.eclipse.team.cvs.core +> plugin.xml Open the Overview tab of the plugin.xml and click Launch an Eclipse application to start an new Eclipse test instance that uses this patch version of the plugin. In this new instance check the sspi connection by selecting File => Import => CVS => Projects from CVS => Next Create a new repository location with (Note apply the settings from comment #25 https://bugs.eclipse.org/bugs/show_bug.cgi?id=41097#c25 first): Host: <cvs host IP> Repository path: <cvsroot> User: <username> Connection type: sspi Click Next Select Use an existing module to browse the CVS repository. Close the Eclipse test instance. To rebuild this plug-in select File => Export => Plug-in Development => Deployable plug-ins and fragments and click Next. In the Available Plug-ins and Fragments check org.eclipse.team.cvs.core Set Destination Directory for example D:\download and click Finish. Close Eclipse. Move or copy D:\download\plugins\org.eclipse.team.cvs.core_3.3.2.200806141524.jar to your C:\java\eclipse\plugins directory. Don't forget to rename the original jar to something like org.eclipse.team.cvs.core_3.3.2.r33x_20080128.jar.old.
Created attachment 104965 [details] Patched CVS plug-in jar based on R3_3_maintenance
Just curious: where is the code that does the SSPI authentication itself?
That is done with CVSNT's own client C:\dev\vcs\cvsnt-2.5.03.2382\extnt.exe which should be configured in Eclipse (see comment #25). The code is just there to recognize :sspi:user@host:/cvs and handle it as if it was :ext:user@host:/cvs by extending the ExtConnectionMethod. And by using the mapping in extnt.ini: [<host>] protocol=sspi hostname=<host> extnt.exe knows it must handle SSPI authentication.
Unless I am missing something, given what is described in comment 25, there is no reason to even have an sspi connection method since you could just use ext and configure it as you've indicated in comment 25. The patch that is in comment 31 looks mostly to be a no-op except for the prompting code. Why do you need the prompting code (i.e. the patch to CVSRepositoryLocation)? In comment 25, you indicated that it was because you didn't like to store your password but that should be handled properly (i.e. if the password is null, the user should be prompted). Were you seeing different behaviour when using the ext connection method?
That is correct (that's why the solution was easy). It is just a convenience method because I have been working with a GUI client WinCVS and checkout using sspi. Thus all my CVS\Root files are infested with :sspi:jjasper@192.168.0.26:/cvs entries. About the prompting code. When I run CVS Repository Exploring with this patch in place I have the following results: - :sspi:jjasper@192.168.0.26:/cvs I'm prompted for a password - :ext:jjasper@192.168.0.26:/cvs I get 'Error fetching resource list from repository Reason: The server reported an error: 0 [extnt] connect aborted: server 192.168.0.26 rejeced access to /cvs' I will take another look at the code that created this message. Because the current solution requires you to enter the correct password the first time otherwise you need to restart Eclipse.
OK, there seem to be two issues here: 1) It is convenient to have an sspi connection method for interop purposes. In my opinion, this should be a separate plug-in even though it only contains one class (just as ssh is a separate plug-in) 2) When using the ext ssh connection method (and potentially others), there are prompting issues when no password is available. In my opinion, this should be logged as a separate bug since the issue is not just applicable to sspi.
Created attachment 104980 [details] Single patch file for SSPI support and EXT support connect problem Single patch file for SSPI support and EXT support connect problem See comment #25 and comment #32 for additional information
Created attachment 104981 [details] Patched CVS plug-in jar based on R3_3_maintenance
Is there any SSPI support for Eclipse that mere mortals will be able to configure at this point? I don't really know or want to know what SSPI is, but I need to connect to an SSPI server via Cisco Vpn Client using CVSNT & WinCVS. Pretty awful mix of tools there that I was hoping to replace w/Eclipse bliss :-)
Created attachment 138216 [details] Single patch file for SSPI support and EXT support connect problem See 1. https://jmodalwindow.dev.java.net/manual/dpl/html/integrated.development.environment.html#ide.eclipse.plugin.install.guide.cvs for an install guide. 2. https://jmodalwindow.dev.java.net/manual/dpl/html/integrated.development.environment.html#ide.eclipse.plugin.config.cvs.repo for a configuration guide. 3. https://jmodalwindow.dev.java.net/manual/dpl/html/tips.and.tricks.html#tip.eclipse.patch.test.build.plugin for a manual to apply this patch yourself.
Hi, the version for this plugin that I've got installed is 3.3.200.I20090430-04-08. The company I'm working on is using the sspi protocol, so I can't access the repository from eclipse. This seems to be a good alternative, but I'm afraid to blow things up by applying the patch to a more recent version than the one mentioned. Is there any workaround for me? Thanks in advance.
We have CVSNT working with SSPI by using Eclipse's Ext Connection. You need a version of CVSNT installed locally. Edit "extnt.ini" in "C:\Program Files\CVSNT" and add the following section: [your-cvs-id] protocol=sspi hostname=your.cvs.host.name directory=/path/to/CVSROOT where * [your-cvs-id] is any identifier you want to use for this connection * hostname = the same host as your CVS connection string * directory = the same as the CVS Repository location in your CVS connection string. In eclipse Windows > Preference browse to Team > CVS > Ext Connection * CVS_RSH=C:\Program Files\CVSNT\extnt.exe * Parameters={host} * CVS_Server=cvsnt Now open the CVS Repository Exploring perspective and create a new Repository Location. Your CVS connection string will look like this: :ext:.@your-cvs-id:/path/to/CVSROOT Notes: * adjust to match the values from ext.ini * Leave the user name as . since SSPI uses your windows login details. Paste the CVS connection string from into the host field (Eclipse will automatically parse this and populate the correct fields). Click Finish and you should have working CVS access. You will need to re-checkout your project using this new connection, so make sure you have committed changes from the non-ext checkout (e.g. by using TortoiseCVS)
Thanks for your reply. I must be doing something wrong about this. Our connection string is :sspi:aambrosio@EIPBRSDESK:2401/cvs/repositories/matrix I followed your instructions in the extnt.ini file without mentioning the port (don't know if I should) My final extnt.ini file looks like: [cvs.cvsnt.org] protocol=sserver hostname=cvs.cvsnt.org directory=/usr/local/cvs [aambrosio] protocol=sspi hostname=EIPBRSDESK directory=/cvs/repositories/matrix then, in eclipse, in the Ext Connection Method, I put C:\Program Files\cvsnt\extnt.exe {host} cvsnt finally, when creating a new repository, I pasted the connection string into the "use custom label field" it looks like this: :ext:.@aambrosio/cvs/repositories/matrix And it populated the fields accordingly Unfortunately, I keep receiving a message from eclipse that reads: Unknown response received from cvs server. No details available. I tried the same configuration with and extra line in the .ini file : Port=2401 I also tried specifying the port in eclipse. Same results. I apologize for bothering you further. Is there anything I'm doing wrong? Thanks in advance.
I will email you directly so this bug doesn't turn into support.
Hi, I was working on gserver support in Eclipse's CVS plug-in. Unfortunately I'm stuck at credential verification. I'm attaching a small test case which should illustrate basic GSSAPI authentication (the plan is to get a pure Java implementation working). IMO once that works, I think integrating it into the CVS plug-in code should be alright (since I'll move forward with Alex Blewitt's work). Anybody having an idea what's wrong with the attached code? I get a GSSException when I request mutual authentication. I'm able to establish a security context when set to false, but verifying MIC's fails then. The content of csLogin.conf is as follows: Client { com.sun.security.auth.module.Krb5LoginModule required; }; Login { com.sun.security.auth.module.Krb5LoginModule required refreshKrb5Config=true; }; Command to run: $ java \ -Djava.security.krb5.config=/etc/krb5.conf \ -Djava.security.auth.login.config=csLogin.conf -Dsun.security.krb5.debug=true \ Client cvs.server.com 2401 I'd very much appreciate pointers in any direction. Thanks!
Created attachment 176036 [details] GSS example client
(In reply to comment #46) > I will email you directly so this bug doesn't turn into support. Hi Barrie Treloar, I'm encountering the same issue as <Andre Ambrosio> mentioned above, could you please kindly supply some advice in terms of the issue to me? Mine connection string is something like :ext:.@riskIntegrator:/ri and i've configured the extnt.ini as well by adding the following [riskIntegrator] protocol=sspi hostname=CNSHAERSRI05 directory=/ri Thanks a lot in advance Jack
Jack, Andre had an incorrect CVS string, it was missing a colon between the host name and cvsroot. Here are some trouble shooting tips. Check that cvsnt works on the command line. This should give you a better error message by using cvsnt instead of via eclipse. Make sure you set the CVS_RSH environment variable in the windows command: CVS_RSH=C:\Program Files\CVSNT\extnt.exe If you forget to do this, you will see an error like below: ' from cvs servering: unrecognized response `'ssh' is not recognized as an internal or external command, ' from cvs servering: unrecognized response `operable program or batch file. cvs [version aborted]: end of file from server (consult above messages if any) Now try running the "version" command, this will contact the server and report both the client and server versions. cvs -d :ext:.@riskIntegrator:/ri version If all works well you will see output like: Client: Concurrent Versions System (CVSNT) 2.5.03 (Scorpio) Build 2382 (client/server) Server: Concurrent Versions System (CVSNT) 2.5.03 (Scorpio) Build 2260 (client/server) Also I wonder if there is a typo in your hostname. hostname=CNSHAERSRI05 Could it be CNSHARESRI05 ? Once you have the command line working it should be simple to fix the Eclipse setings.
Hi Barrie, Sorry I just saw the mail and it's several months ago :-) I followed the steps you've given and unfortunately it doesn't work for me. I use cvsnt Client: Concurrent Versions System (CVSNT) 2.0.51d (client/server) Server: Concurrent Versions System (CVSNT) 2.0.51d (client/server) I saw your version is 2.5, so i bet maybe it does not support the version 2.0 Anyway, i gave up using eclipse though it facilitates syncronization with development. Now i'm using TortoiseCVS alternatively Cheers Jack (In reply to comment #50) > Jack, Andre had an incorrect CVS string, it was missing a colon between the > host name and cvsroot. > Here are some trouble shooting tips. > Check that cvsnt works on the command line. This should give you a better error > message by using cvsnt instead of via eclipse. > Make sure you set the CVS_RSH environment variable in the windows command: > CVS_RSH=C:\Program Files\CVSNT\extnt.exe > If you forget to do this, you will see an error like below: > ' from cvs servering: unrecognized response `'ssh' is not recognized as an > internal or external command, > ' from cvs servering: unrecognized response `operable program or batch file. > cvs [version aborted]: end of file from server (consult above messages if any) > Now try running the "version" command, this will contact the server and report > both the client and server versions. > cvs -d :ext:.@riskIntegrator:/ri version > If all works well you will see output like: > Client: Concurrent Versions System (CVSNT) 2.5.03 (Scorpio) Build 2382 > (client/server) > Server: Concurrent Versions System (CVSNT) 2.5.03 (Scorpio) Build 2260 > (client/server) > Also I wonder if there is a typo in your hostname. > hostname=CNSHAERSRI05 > Could it be > CNSHARESRI05 > ? > Once you have the command line working it should be simple to fix the Eclipse > setings.
March Hare Software are the authors of CVSNT. Our own guide to connecting Eclipse and CVSNT can be downloaded from here: http://www.march-hare.com/cvspro/?pdf=k CVSNT 2.0.51 and CVSNT 2.5.03.2382 have serious known security issues as listed here: http://www.march-hare.com/cvspro/security.htm If you are using CVSNT 2.0.51, CVSNT 2.0.58, CVSNT 2.5.01, CVSNT 2.5.02 or CVSNT 2.5.03.2382 we strongly recommend you upgrade immediately to CVSNT 2.8.01 (CVS Suite 2009). We've been interested in developing a CVSNT eclipse plugin for a while - or significantly 'improving' the existing CVS plugin to support CVSNT specific features. I'll take note of this Eclipse bug number for future reference.
We have been using the original/modified version (vc++6) above with CVSNT 2.5.xx (Scorpio release) and WinXP 32 bit client. It has worked flawlessly. We have recently upgrade to Win7x64 with Eclipse Indigo (3.7) and JDK 6X64 and both the native DLL as well as the plug-in broke. It took a few hours but we now have a version that runs on Win7 X64, Eclipse Indico build 20110615-060 THe CVSNT Server is 2.5.x on Win2K3 32 bit. Looks like this thread has migrated away from the original native DLL route. IF there are still interests in the native DLL, reply to this thread and I can make the code/binaries available.
(In reply to comment #53) > We have been using the original/modified version (vc++6) above with CVSNT > 2.5.xx (Scorpio release) and WinXP 32 bit client. It has worked flawlessly. That release is over 6 years old! As advised (above) CVSNT 2.5.03.2382 (Scorpio) has serious known security issues as listed here: http://www.march-hare.com/cvspro/security.htm > We have recently upgrade to Win7x64 with Eclipse Indigo (3.7) and JDK 6x64 and > both the native DLL as well as the plug-in broke. Note: Eclipse recommends JDK 5R11 for use with Eclipse 3.7 on windows 7: http://www.eclipse.org/downloads/moreinfo/jre.php I just now today tested CVSNT 2.8.01 on Windows 7 SP1 x64 with Eclipse Indigo (3.7) Build id: 20110615-0604 and Sun JDK 6u26. I loaded the org.eclipse.swt.examples following the documentation that comes with CVSNT 2.8.01. All worked OK. If you experience any problems, please e-mail the technical support team as described in the CVSNT Eclipse eBook that comes with 2.8.01. http://www.march-hare.com/cvspro/?pdf=k There is no need to modify or custom build either CVSNT or Eclipse to use it. To resolve incompatibility you should follow the vendors advice and upgrade to a recent release like CVSNT Soolin 2.8.01 (CVS Suite 2009).
(In reply to comment #54) > (In reply to comment #53) > > > We have been using the original/modified version (vc++6) above with CVSNT > > 2.5.xx (Scorpio release) and WinXP 32 bit client. It has worked flawlessly. > > That release is over 6 years old! As advised (above) CVSNT 2.5.03.2382 > (Scorpio) has serious known security issues as listed here: > http://www.march-hare.com/cvspro/security.htm Thkx. Will pass this info on to the folks who manage the CVSNT Server. > > > We have recently upgrade to Win7x64 with Eclipse Indigo (3.7) and JDK 6x64 and > > both the native DLL as well as the plug-in broke. > > Note: Eclipse recommends JDK 5R11 for use with Eclipse 3.7 on windows 7: > http://www.eclipse.org/downloads/moreinfo/jre.php > > I just now today tested CVSNT 2.8.01 on Windows 7 SP1 x64 with Eclipse Indigo > (3.7) Build id: 20110615-0604 and Sun JDK 6u26. I loaded the > org.eclipse.swt.examples following the documentation that comes with CVSNT > 2.8.01. All worked OK. If you experience any problems, please e-mail the > technical support team as described in the CVSNT Eclipse eBook that comes with > 2.8.01. > http://www.march-hare.com/cvspro/?pdf=k > > There is no need to modify or custom build either CVSNT or Eclipse to use it. > To resolve incompatibility you should follow the vendors advice and upgrade to > a recent release like CVSNT Soolin 2.8.01 (CVS Suite 2009). The issue that I encountered wasn't related to JDK version. While Eclipse.org tested with JDK 5R11, we have always had no issue running JDK 6 even with Eclipse 3.4+. JDK 5 itself has its share of GC problem. The real issue was that the plug-in (java code) didn't properly register itself as a plugin so SSPI protocol didn't appear in the Add CVS Repository dialog. So i am curious here as to whether or not march-hare has plan to support a true SSPI plugin rather than using EXT protocol to execute and EXE which then reads some *.INI file to perform the real SSPI protocol underneath? While it works, it's just a lot more setup needed than what the original author by Jacob S Barret from amduat.net (? any relation here? :) ) had done. I didn't look into all the details of the March-hare link, but, as a side question, with the *.INI approach, is it able to support multiple CVSNT Servers concurrently ? Anyway - I will also pass the info on to the team. Thanks for your reply.
CVS plugin is in deep maintenance mode and pretty much everyone moved away from it. Thus it's fair to say we are not going to do anything here.
