Bug 146782 - error accessing dev.eclipse.org cvs repository using extssh
Summary: error accessing dev.eclipse.org cvs repository using extssh
Alias: None
Product: Fedora
Classification: Fedora
Component: java-1.4.2-gcj-compat
Version: rawhide
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Thomas Fitzsimmons
QA Contact:
: 151159 152361 155576 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-01 16:47 UTC by Rick Moseley
Modified: 2007-11-30 22:10 UTC (History)
10 users (show)

Clone Of:
Last Closed: 2006-02-08 13:33:10 UTC

Attachments (Terms of Use)
eclipse log for NPE (4.28 KB, text/plain)
2005-11-12 17:07 UTC, Axon
no flags Details

Description Rick Moseley 2005-02-01 16:47:40 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
When setting up to access a cvs repository using extssh an error
occurs when the Finish" button is clicked.  An error message appears
in the xterm window where eclipse was started from immediately in
concert with the clicking of the "Finish" button:

java.security.NoSuchAlgorithmException: DH

An error window then appears that has the following verbage:

Error validating location: ""

Keep location anyway?

I know the repository is OK because I can access it from another
machine.  Also, I can access it when I change the "Connection type:"
to use "pserver" instead of "extssh".

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Select CVS repostiroy view
2. Click on "Add new repository" icon
3. Try to add a repository with a usr name and password and select
"extssh" as the "Connection type:".
4. Click on "Finish"


Actual Results:  An error window apears as descibed above and a
message appears in the xterm window as described above.

Expected Results:  Successful access to the repository.

Additional info:

rpm -qa | grep eclipse

rpm -qa | grep cj

Comment 1 Andrew Overholt 2005-03-20 14:57:55 UTC
*** Bug 151159 has been marked as a duplicate of this bug. ***

Comment 2 Ziga Mahkovec 2005-03-20 16:35:45 UTC
Eclipse uses the JCraft JSch plugin for SSH2 connections.  SSH2 (and in turn
JSch) requires a Diffie-Hellman (DH) key exchange implementation, which libgcj
doesn't provide.  A simple test:


throws the above NoSuchAlgorithmException.

As I understand it, GNU Crypto is supposed to provide the extra crypto
algorithms.  The gnu-crypto-2.0.1 package does seem to have a DH implementation,
but it doesn't have the necessary JCE providers.  I don't suppose it would be
too difficult to implement them though.

However, bouncycastle has a pretty complete JCE implementation.  I was able to
get extssh working in Eclipse using the following steps:

  - Install bouncycastle from jpackage.org
    $ sudo yum install bouncycastle-jdk1.4

  - Link the extension
    $ sudo ln -s /usr/share/java-ext/bouncycastle-jdk1.4/bcprov.jar \

  - Install the security provider
    $ sudo sh -c "echo
'security.provider.2=org.bouncycastle.jce.provider.BouncyCastleProvider' >> \

I was then able to check out a project using the extssh connection type.

Comment 3 Thomas Fitzsimmons 2005-03-21 18:46:36 UTC
I'll add a dependency on bouncycastle to java-1.4.2-gcj-compat.

Comment 4 Andrew Overholt 2005-04-28 20:04:21 UTC
*** Bug 152361 has been marked as a duplicate of this bug. ***

Comment 5 Andrew Overholt 2005-05-04 14:32:17 UTC
I still get this with what I think are the latest versions of everything:

$ rpm -q jessie java-1.4.2-gcj-compat gnu-crypto jsch eclipse-platform gcc

Tom, any ideas?

Comment 6 Thomas Fitzsimmons 2005-05-04 15:36:50 UTC
I'm working on a patch that will merge Jessie and parts of GNU Crypto into GNU
Classpath.  I'll also merge in the DH parts of GNU Crypto, then retest this. 
I'll keep you posted.

Comment 7 Thomas Fitzsimmons 2005-05-11 19:18:16 UTC
We can't put bouncy castle in for FC4 now.  It is big enough that we'd need to
remove something to maintain FC4's 4 CD limit.  Removing things at this late
date in the release cycle was deemed too risky by releng.

I'll try to push bouncy castle into Rawhide as soon as FC4 is released.  Then it
should be available as a 0-day upgrade for people using Eclipse's extssh mode.

In the meantime I'll work on the upstream merge that will make all these
standalone crypto packages unnecessary.

Comment 8 Thomas Fitzsimmons 2005-05-16 22:24:07 UTC
*** Bug 155576 has been marked as a duplicate of this bug. ***

Comment 9 Thomas Fitzsimmons 2005-05-17 22:01:36 UTC
OK, I've built the Bouncy Castle provider into java-1.4.2-gcj-compat.  There's
one outstanding libgcj patch that I've sent to Jakub for inclusion in the FC4
libgcj RPMs.  Once that's in extssh support will work and I'll close this bug.

Comment 10 Thomas Fitzsimmons 2005-05-26 04:32:57 UTC
This fix worked perfectly on my workstation but broke javac in beehive.  I
debugged the problem though, and it seemed to be a libgcj miscompilation.  I may
try building into beehive again, against the latest gcc.

Comment 11 Thomas Fitzsimmons 2005-05-26 22:16:42 UTC
I tried again to fix this, even testing manually in the buildroot before
actually building into beehive.  But the same problem showed up, again

As a workaround, you can try getting the java-1.4.2-gcj-compat SRPM,
uncommenting the Bouncy Castle sections and rebuilding on your workstation.  I'd
appreciate hearing about it if anyone has a problem with it.

Unfortunately we'll have to defer actually fixing this in the distro until
Bouncy Castle is merged into libgcj.  Closing as deferred to post-FC4 Rawhide.

Comment 12 Thomas Fitzsimmons 2005-09-13 22:15:10 UTC
Reopening for FC5.  Casey Marshall just committed a JCE provider to GNU
Classpath CVS; I haven't tested it yet but I'll keep this bug report up-to-date.

Comment 13 Chris Hubick 2005-09-13 22:29:48 UTC
I tried (and failed) to get this working using Bouncy Castle from the
instructions above.

I was receiving:
Exception in thread "main" java.lang.NoSuchFieldError: field
org.bouncycastle.asn1.pkcs.PKCSObjectIdentifiers.id_RSAES_OAEP was not found.
   at org.bouncycastle.jce.provider.BouncyCastleProvider.BouncyCastleProvider()
(Unknown Source)
   at java.lang.Class.newInstance() (/usr/lib/libgcj.so.6.0.0)

As far as I can tell using Eclipses reflection, that field is present in the class.

I posted the details on the email list:
but it went unresolved.

Just an FYI for reference.

(p.s. My system has been updated using JPackage, and is decidedly *not* pure FC4).

Comment 14 Axon 2005-11-12 17:06:08 UTC
Not sure if this is related, but I'm getting a NPE thrown by the
com.jcraft.jsch.jce.DH class (see attached log) when I attempt to use extssh to
connect with a CVS server. Would this be related to this issue and is there a
temporary workaround?

Comment 15 Axon 2005-11-12 17:07:08 UTC
Created attachment 120986 [details]
eclipse log for NPE

Comment 16 Thomas Fitzsimmons 2006-02-03 05:25:01 UTC
The NoSuchFieldError was the result of GNU Crypto 2.0.1 including different
versions of some BouncyCastle classes.  I updated Rawhide to GNU Crypto 2.1.0
which no longer contains these classes and in doing so I fixed Eclipse's extssh
CVS access mode.

Comment 17 Chris Hubick 2006-02-03 05:48:43 UTC
Hey great!  That removes a fairly big blocker on my use of Free Eclipse.  (now
all I need is a working debugger :)  Much Thanks!

Comment 18 Andrew Overholt 2006-02-06 19:55:17 UTC
This does not work for me with rawhide.  I've tried on both x86 and on ppc and I
get the same "Error.  Auth failed." on both machines.

Comment 19 Thomas Fitzsimmons 2006-02-07 16:24:26 UTC
Any stacktrace?

Comment 20 Thomas Fitzsimmons 2006-02-08 05:57:14 UTC
What you're seeing may simply be an actual authentication failure.  I get the
same failure if I move my .ssh keys out of my home directory and then try to
connect to an extssh repository.  But that's expected, since I'm trying to do
something I'm not authorized to do (login using a password only).

Comment 21 Andrew Overholt 2006-02-08 13:33:10 UTC
Yeah, it looks like it's something with my keys.  I don't know what, but it
looks like it's my bug.  Closing.

Note You need to log in before you can comment on or make changes to this bug.