Bug 146782

*** Bug 151159 has been marked as a duplicate of this bug. ***

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:

  java.security.KeyPairGenerator.getInstance("DH");

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 \
                 /usr/share/java-ext/bcprov.jar

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

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

I'll add a dependency on bouncycastle to java-1.4.2-gcj-compat.

*** Bug 152361 has been marked as a duplicate of this bug. ***

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
jessie-1.0.0-5
java-1.4.2-gcj-compat-1.4.2.0-40jpp_18rh
gnu-crypto-2.0.1-1jpp_2fc
jsch-0.1.18-1jpp_1fc
eclipse-platform-3.1.0_fc-0.M6.14
gcc-4.0.0-2

Tom, any ideas?

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.

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.

*** Bug 155576 has been marked as a duplicate of this bug. ***

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.

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.

I tried again to fix this, even testing manually in the buildroot before
actually building into beehive.  But the same problem showed up, again
unreproducable.

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.

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.

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:
http://www.redhat.com/archives/fedora-devel-java-list/2005-July/msg00158.html
but it went unresolved.

Just an FYI for reference.

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

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?

Created attachment 120986 [details]
eclipse log for NPE

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.

Hey great!  That removes a fairly big blocker on my use of Free Eclipse.  (now
all I need is a working debugger :)  Much Thanks!

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.

Any stacktrace?

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).

Yeah, it looks like it's something with my keys.  I don't know what, but it
looks like it's my bug.  Closing.