Re: AW: [geclipse-dev] GSISSH

[Thomas Köckerbauer <tkoeck@xxxxxxxxxx>]

Hi

Since we have not found a solution on the gsissh jsch patch packaging yet, 
I've now commited the com.jcraft.jsch plugin from my workspace (which includes 
the patch) to CVS, just for having it in some repository (I do not like having 
code only in my workspace).
If we find a solution we can change/delete the plugin on CVS later on.


Cheers,
Thomas


On Wednesday 13 May 2009 18:11:40 Thomas Köckerbauer wrote:
> Hi
>
> > [...]
> >
> > On the other hand if we manage to push your changes to the upstream
> > author they will end up in the Orbit bundle used by Eclipse... :)
> > We could write them an email (they welcome suggestions etc in
> > jsch@xxxxxxxxxx) and ask.
> >   How does/would your code connect to Globus? is it still possible to
> > have your modified jsch plugin and use the other auth mechanisms even if
> > you don't have any globus library around?
>
> I terms of adding the functionality not many changes where necessary. I
> basically took the class for kerberos authentication and created one for
> GSI basing on that one (since both use the gssapi).
>
> All other changes where necessary for getting that added to jsch. The next
> thing I had to change was the UserAuthGSSAPIwithMIC class that checks which
> OIDs (Object IDs i.e. which gssapi auth types) are supported by the server
> and the client and tries those which are supported by both. I had to change
> that class since all supported OIDs (only the kerberos in the original
> version) are listed in an array in there. And there is also a 2nd array
> which contains Strings (corresponding to the OIDs in the 1st array) that
> are used as a key to look the up the name (also a String) of the class
> implementing the specific gssapi authentication method in a hash map.
> Then I changed the JSch class in which the hash map is filled (I added an
> entry there which defines the name of the class I added to be used for the
> gsi auth method) (This could also be done by some other class by calling
> the setConfig() method of the JSch class, but due to the org.eclipse.jsch
> plugin I have no direct access to the JSch class).
>
> Adding that to the upstream version is somewhat difficult, the GSI specific
> class has a ton of dependencies (org.globus, eu.geclipse.core,
> eu.geclipse.core.reporting, eu.geclipse.globus, org.eclipse.core.runtime,
> maybe some others too). The other stuff is just there to add it to the list
> of available auth mechanisms.
>
> Because of the dependencies I guess it is no option to put the GSI specific
> class into the jsch plugin.
> The best way would be to somehow register the GSI specific class in the
> jsch plugin from another plugin outside, but this currently not possible
> for several reasons:
> * The OIDs and the keys of the implementing classes for the hash map are
>   listed directly in the GSSAPI class.
> * Only the class names are in the hash map, and they are used to create
>   instances (using reflection) i.e. the jsch plugin classloader is used for
>   trying to create an instance, which will fail if the class is not in the
>   same plugin
>
>
> Cheers,
> Thomas
>
>
> _______________________________________________
> geclipse-dev mailing list
> geclipse-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/geclipse-dev