| Jeff,
It would be better if there was some mechanism to add additional authentication methods to JSch without requiring the hold plugin to be replaced. I presume you looked into this and there is no viable alternative? If so, then I wouldn't be opposed to distributing the fragment via the PTP update site as long as there are suitable warnings displayed to the user and the fragment must be installed manually.
Regards, Greg On Apr 10, 2012, at 4:57 PM, Jeffrey Overbey wrote: As I mentioned on the ptp-dev call today, we've added support for GSI authentication to the SSH implementation in Eclipse (JSch). Unfortunately, since this requires changing the internals of JSch, we have to distribute this as an Eclipse Feature Patch. It installs like a normal feature (from an update site), but it replaces the com.jcraft.jsch plug-in in the Eclipse Platform with our own.
I also added support for MyProxy Logon, which works in tandem with this, but that's just a normal Eclipse feature, not a patch.
We're prepared to distribute this independently via an update site hosted at NCSA, but if it's possible to distribute it through the PTP update site, that might be worth considering.
Pros to distributing via the PTP site are: - GSI authentication is widely used on XSEDE/TeraGrid resources, which PTP is targeting. (The g-Eclipse guys prototyped GSI auth support, somewhat differently from us -- so they recognized the need for this too -- but they never released it.)
- It will be easier for users to install these features from the PTP update site than from a separate, more obscure NCSA update site.
- Our change to JSch is very minimal (just a few lines of code to add a new authentication method), so this is, in theory, a low-risk patch.
Cons are: - Patching the Platform is dangerous. If something goes wrong, it can destroy your entire Eclipse installation, or at least make it unusable. If this happens to any users, it would reflect very poorly on PTP.
- Swapping out the Platform's JSch plug-in automatically adds GSI auth support to RSE, Remote Tools, and every other Eclipse plug-in that uses SSH. That's nice... except, if there are any bugs, they will also be manifested in RSE, Remote Tools, and every other Eclipse plug-in that uses SSH. Differential testing against an un-patched instance of Eclipse is often the only way to identify the JSch patch as the cause.
- This patches a very specific version of JSch. When the Platform upgrades their version of JSch, someone will have to re-implement this patch. And JSch does not have a nice, objected-oriented mechanism for contributing new authentication methods... this is literally a hacked-up version of the JSch code.
- The code has two library dependencies (JGlobus and BouncyCastle TLS), and the NCSA code is from several different authors... so the IP process will probably be long and tedious.
It's probably too late to consider this for the Juno release -- especially since the IP review will be pretty involved, IMHO. I think it would be good to test it on some users at NCSA before inflicting it on the world anyway, especially to see if any problems arise. But I thought I'd mention this as a possibility and see if it's something we should pursue, perhaps after Juno...
Jeff
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
|
