Community
Participate
Working Groups
Apparently Jsch 0.1.45 will be released soon. We should look at consuming it when it is available. Changes since version 0.1.44: - bugfix: fields referred by multiple threads simultaneously should be volatile. - bugfix: use local window size offered by the remote in sftp put. - bugfix: SftpProgressMonitor#init was not invoked in sftp put for input-stream. - bugfix: sftp protocol version 3, 4 and 5 should allow only UTF-8 encoding. - bugfix: Channel Subsystem had failed to set X forwarding flag. - bugfix: Channel X11 had leaked some resources. - bugfix: packet compression may break sessions in some case(transferring deflated data). - bugfix: failed to set dev-null for logger - bugfix: even in sftp protocol version 3 session, some sftpd sends data packets defined in sftp protocol 6 ;-( working around it. - bugfix: ChannelSftp file globbing logic had missed the string "foo\\\*bar" as a pattern. - change: to improve sftp-put performance, send multiple packet at one time. - change: wait/notify will be used instead of sleep loop in establishing channel connections. - change: increasing local window size for sftp get. - feature: key-exchange method "diffie-hellman-group14-sha1" (RFC4253#section-8.2) - feature: KeyPair#getPlulicKeyCommment() is added.
Sounds like we should go ahead with this. PW
A couple more changes than mentioned in comment 0 have gone into JSch as per http://www.jcraft.com/jsch/ChangeLog : - bugfix: sequential accesses to ChannelSftp by multiple threads may break its I/O channel. https://bugs.eclipse.org/bugs/show_bug.cgi?id=359184 FIXED - bugfix: KeyPair.load can not handle private keys cyphered with AES. FIXED - change: updating copyright messages; 2010 -> 2011 - change: src/com -> src/main/java/com In fact the TM project will need JSch-0.1.45 to get bug 359184 fixed (a prerelease of an "Eclipsified" JSch-0.1.45 that can be used as a plugin is attached to that bug). Bug 326526 comment 40 indicates interest in JSch-0.1.45 in order to get AES-128-CBC support for private key encryption.
FYI, upcoming JSch-0.1.46 is being discussed related to supporting the ssh-agent for authentication: bug 179924 comment 19
JSch-0.1.46 has been released today, I think we should shoot for adopting that version. Most notably, 0.1.46 adds support for optionally using an agent (ssh-agent on Linux or pageant on Windows) for Authentication - a feature which has repeatedly been requested. From the http://www.jcraft.com/jsch/ChangeLog : Changes since version 0.1.45: - bugfix: in the agent forwarding mode, "ssh-add -l" on the remote will freeze. FIXED - bugfix: requests should not be sent to the closed channel. FIXED - bugfix: ChannelShell#setAgentForwarding(true) will cause resource leaks. FIXED - change: for the efficiency, channel opening will be delayed in local port forwarding. - change: added examples/Sudo.java to demonstrate sudo on exec channel. - change: authentication trials will be failed at 6 failures by the default. - change: updating copyright messages; 2011 -> 2012 - feature: added JSch#setIdentityRepository(IdentityRepository irepo) to integrate with jsch-agent-proxy. I noticed that no CQ has been created yet for JSch-0.1.45 or 0.1.46, and the CQ deadline for Juno is TOMORROW Feb 3. I could add a CQ on behalf of my project (TM), but it may make more sense for Platform/Team to step up ... Szymon, Tomas ?
Filed two CQs: * https://dev.eclipse.org/ipzilla/show_bug.cgi?id=6211 for JSch-0.1.45 * https://dev.eclipse.org/ipzilla/show_bug.cgi?id=6212 for JSch-0.1.46
Created attachment 210506 [details] JSch-0.1.46 as Eclipse project ready to go into Orbit I've taken the time yestderday packaging up JSch-0.1.46 in the format needed for Orbit (with about, MANIFEST, source bundle etc). Find the resulting project attached. Importing this project into a Workspace also makes it possible to test the version (when running a debuggee out of the workspace). Note that I have added an optional dependency on jzlib in order to address bug 343416. The about.html has the "Sun" reference for Java replaced to "Oracle" and an SSH trademark notice added.
Created attachment 210509 [details] JSch-0.1.46 bundle ready for dropins Attached is the binary runnable JSch-0.1.46 bundle for testing. Unfortunately it looks like just dropping this into dropins/ is not sufficient since the org.eclipse.platform feature forces using the older JSch. To fix this, file eclipse\features\org.eclipse.platform_*\feature.xml needs to be edited, replacing the "version=" field for JSch with the new version: version="0.1.46.201202031301" I have installed the bundle like this into my development environment and will keep it there for testing (I'd appreciate others do the same to ensure the bundle is good).
Martin, are we going to process JSch-0.1.45 or should I withdrawn the CQ?
I think you can withdraw 0.1.45 -- even in the unlikely case there's a severe problem with 0.1.46 I'd rather get that fixed by upstream and adopt 0.1.47 than go back down. I'm updating the summary of the bug accordingly.
(In reply to comment #9) > I think you can withdraw 0.1.45 -- even in the unlikely case there's a severe > problem with 0.1.46 I'd rather get that fixed by upstream and adopt 0.1.47 than > go back down. Makes sense to me, withdrawn.
I have reviewed "about.html" in attachment 210509 [details], and have not found any problem in it. JSch 0.1.46 has not done any changes about cryptography.
(In reply to comment #7) > Created attachment 210509 [details] > JSch-0.1.46 bundle ready for dropins Possible problem here: it does not import non-java.** JRE packages. It will not then work in all OSGi environments, including Equinox in its default configuration due to the change in bug #344850; compare NetBeans bug #208616 [1]. Recommend adding entries to Import-Package (at least javax.crypto, javax.crypto.spec, javax.crypto.interfaces). [1] https://netbeans.org/bugzilla/show_bug.cgi?id=208616
Yes, all non java.* packages used by a bundle in orbit should be imported. This is the only way to ensure the bundle will work on a compliant OSGi Framework.
(In reply to comment #12) > (In reply to comment #7) > > Created attachment 210509 [details] > > JSch-0.1.46 bundle ready for dropins > > Possible problem here: it does not import non-java.** JRE packages. It will not > then work in all OSGi environments, including Equinox in its default > configuration due to the change in bug #344850; compare NetBeans bug #208616 > [1]. Recommend adding entries to Import-Package (at least javax.crypto, > javax.crypto.spec, javax.crypto.interfaces). > > [1] https://netbeans.org/bugzilla/show_bug.cgi?id=208616 The "org.ietf.jgss" package will be referred in using the auth method "gssapi-with-mic", and "com.jcraft.jzlib" will be also in enabling the packet compression. So, those packages should be also added to it. But, if the next release does not include jzlib[1], it may cause a problem. [1] https://dev.eclipse.org/ipzilla/show_bug.cgi?id=6218 I can not visit above page, so if jzlib has been already accepted, please ignore the last sentence.
*** Bug 374411 has been marked as a duplicate of this bug. ***
Will this be part of Juno? The currently shipped version 0.1.41 isn't able to unlock my private SSH key, which in turn is annoying since I can't EGit clone any SSH repos using my SSH key.
(In reply to comment #16) > Will this be part of Juno? The currently shipped version 0.1.41 isn't able to > unlock my private SSH key, which in turn is annoying since I can't EGit clone > any SSH repos using my SSH key. Hi Severin the latest that is available from orbit is 0.144. 0.144 already fixes quite some key related problems and works pretty well for me. I'd suggest that you upgrade to that one and see if you still get the errors (I dont).
Hi, I'm the author JSch and working a committer at Eclipse Platform project. You can install jsch 0.1.46 at Eclipse update site, http://eclipse.jcraft.com/ and try it if you still get the errors.
How about the current status of this Bugzilla entry? We had found the slowness of the sftp file download speed, and have improved it in JSch 0.1.48. That improvement will be also useful for RSE. You can install JSch 0.1.48 at our Eclipse plug-in update site, http://eclipse.jcraft.com/site.xml If 0.1.46 is acceptable, it will be also, because there are no changes by third-parties between 0.1.46 and 0.1.48.
(In reply to comment #7) > I have installed the bundle like this into my development environment and will > keep it there for testing Martin, have you noticed anything suspicious after having the bundle installed? If no, given that you already have it at hand, could you upload it to Orbit? (In reply to comment #19) > If 0.1.46 is acceptable, it will be also, > because there are no changes by third-parties between 0.1.46 and 0.1.48. I guess a new CQ would need to be started anyway.
I have committed JSch-0.1.46 to Orbit, and an initial build is available from the Orbit committers area: http://build.eclipse.org/orbit/committers/orbit-I/20120507174954/I20120507174954/ My testing so far looks good, would the Platform team consider adopting the bundle ?
(In reply to comment #21) > I have committed JSch-0.1.46 to Orbit, and an initial build is available from > the Orbit committers area: > http://build.eclipse.org/orbit/committers/orbit-I/20120507174954/I20120507174954/ > > My testing so far looks good, would the Platform team consider adopting the > bundle ? +1 for adopting that bundle.
Let's try to get this in early in RC1. David I guess we need an Orbit build promoted to stable first?
(In reply to comment #19) > http://eclipse.jcraft.com/site.xml I looked at http://eclipse.jcraft.com/plugins/com.jcraft.jsch_0.1.48.jar from this site but its manifest appears incomplete (cf. comment #14): 1. Missing "Import-Package: javax.crypto, javax.crypto.spec, javax.crypto.interfaces, org.ietf.jgss" or something like this, needed in case the OSGi container declines to export these non-java.* packages. 2. Missing "Import-Package: com.jcraft.jzlib;resolution:=optional" (or the Require-Bundle equivalent). http://build.eclipse.org/orbit/committers/orbit-I/20120507174954/I20120507174954/repository/plugins/com.jcraft.jsch_0.1.46.v201205062050.jar fixes #2 but not #1.
We can use an Orbit I-build to "get early" ... but, sounds like I should wait until its fixed? Or confirmed not broken. (Probably should be an Orbit bug for that, or re-open the one that added it to Orbit?)
(In reply to comment #24) > 1. Missing "Import-Package: javax.crypto, javax.crypto.spec, > javax.crypto.interfaces, org.ietf.jgss" or something like this, needed in case > the OSGi container declines to export these non-java.* packages. I checked and it turns out that upstream has zero OSGi headers in there. Jesse can you describe exactly what you think needs to be in there, I can put it into Orbit easily but I don't know for sure what it needs to look like.
ymnk@jcraft.com should probably the authoritative source, but based on the manifest patches needed to make JSch load as a bundle in NetBeans, I would suggest expanding your current header of Import-Package: com.jcraft.jzlib;resolution:=optional to Import-Package: com.jcraft.jzlib;resolution:=optional,javax.crypto,javax.crypto.spec,javax.crypto.interfaces,org.ietf.jgss
I checked the "import" statements in the source code and it looks like this is what I'm going to need ... not sure whether "java.security.*" has to be exposed or would that be found automatically ? Import-Package: com.jcraft.jzlib;resolution:=optional, javax.crypto, javax.crypto.spec, java.security, java.security.interfaces, java.security.spec, org.ietf.jgss
javax.crypto.interfaces is needed as well; com.jcraft.jsch.jce.DH.getE() uses it (without an import). java.security.* should not be needed since an OSGi container exposes any java.* packages automatically.
(In reply to comment #29) Ok, I released it to Orbit as v201205102330 . Many thanks for your diligence ! I thought I had searched for "javax." but missed the one in getE().
The Orbit build has been declared to stable: http://download.eclipse.org/tools/orbit/downloads/drops/I20120509234235/ So Platform should be good to go adopting it.
(In reply to comment #31) > The Orbit build has been declared to stable: > http://download.eclipse.org/tools/orbit/downloads/drops/I20120509234235/ > > So Platform should be good to go adopting it. That doesn't look like a stable build but I might be misunderstanding how Orbit works. David can you take it from here?
(In reply to comment #32) > (In reply to comment #31) > > The Orbit build has been declared to stable: > > http://download.eclipse.org/tools/orbit/downloads/drops/I20120509234235/ > > > > So Platform should be good to go adopting it. > > That doesn't look like a stable build but I might be misunderstanding how Orbit > works. David can you take it from here? I've updated our maps to use the 1.46 version from the orbit I build, for 3.8 and 4.2 for tonights build. Orbit will promote that (or similar) I build around end of Friday, so good to "test" what ever function is touched by this new bundle, and make sure it works as expected before the Orbit promotion. If possible. In case a tweak is needed.
I run jUnits with the Jsch 0.1.46 and also performed some basic manual tests with different authentication methods. I haven't found any regressions.
This change was actually in RC1, unless you marked as RC2 if there's more to do? Or ... if you are NOT seeing it in RC1, then still a bug! (I just checked 4.2, and its there ... let me know if its missing in 3.8). eclipse/plugins/com.jcraft.jsch_0.1.46.v201205102330.jar eclipse/plugins/org.eclipse.jsch.core_1.1.400.v20111202-1616.jar eclipse/plugins/org.eclipse.jsch.core.source_1.1.400.v20111202-1616.jar eclipse/plugins/org.eclipse.jsch.ui_1.1.400.I20111011-0800.jar eclipse/plugins/org.eclipse.jsch.ui.source_1.1.400.I20111011-0800.jar
Ok checked. JSch 0.1.46 is in Eclipse SDK 3.8 RC1 too. Marking fixed.
One note here though: It looks like Eclipse 3.7.x as well as 3.6 and 3.5 shipped the com.jcraft.jsch.source bundle as well with the SDK. I don's see the source bundle in 4.2rc1 so I suggest it should be added.
Created attachment 216064 [details] update to build.properties I see msg in RC1 logs about Unable to find plug-in: com.jcraft.jsch.source_0.1.44.qualifier Note the "44" (instead of 46). So, searched for that, and found its listed in the build.properties of org.eclipse.sdk In the generate.feature@org.eclipse.platform.source line. So, I think fix is simple and safe. Need to go into 4.2 (R4_HEAD) and 3.8 streams (master, merged with 'integration')
Adding John for review for sanity for the build.properties fix. (But, given time, I'll go ahead and start to integrate in, for tonight's build ... since its just "completing" previous fix).
Ok, now fixed ... complete fix for RC2. Thanks for catching Martin.
