Community
Participate
Working Groups
Jsch 0.1.44 has been out for awhile. I noticed the platform ships 0.1.41, it would be nice to ship a newer version to take advantage of fixes. The first step would be to create a CQ that piggybacks on the Orbit CQ. https://dev.eclipse.org/ipzilla/show_bug.cgi?id=4729
Szymon, I believe Team uses Jsch, correct?
I assume this request is for a post 3.7 build because we are in 3.7 shutdown mode and the deadline has passed for Indigo IP requests?
This would be for 3.7 It would be nice of rampdown mode would consider the possibility of updating third party libraries that are out of date but available in Orbit.
Asking John for comment as this is an unusual request. Chris are there specific bug fixes in the newer version of jsch that you are looking for? I think at this point, we are only looking at fixing P1 or P2 defects.
It's more of a convenience for us within Red Hat since we ship the latest version of libraries and have to patch Eclipse a bit if the latest library doesn't ship. More information can be found on this bug... https://bugs.eclipse.org/bugs/show_bug.cgi?id=336874 One thing to note is that EGit/JGit also ships with the latest version of JSch.
I don't support upgrading third party libraries during our release candidates unless there is a critical bug we experience ourselves that it will fix. We should release what we have developed and tested on during the main dev cycle. Note the version number change is small, but jsch does introduce new features with only third segment changes, and there are a number of new features added between 0.1.41 and 0.1.44. FWIW the eGit feature specifies 0.1.37 or greater: <import plugin="com.jcraft.jsch" version="0.1.37" match="compatible"/> I have eGit/jGit installed right now and I only see one copy of jsch in my install. Since it is a small library, it wouldn't be too bad if there were multiple copies anyway. We could consider it for early in 3.6.1 though.
Szymon, you could open a CQ so that the library is approved for our use once 3.7.1 development begins?
(In reply to comment #6) > I don't support upgrading third party libraries during our release candidates > unless there is a critical bug we experience ourselves that it will fix. We > should release what we have developed and tested on during the main dev cycle. > > Note the version number change is small, but jsch does introduce new features > with only third segment changes, and there are a number of new features added > between 0.1.41 and 0.1.44. > > FWIW the eGit feature specifies 0.1.37 or greater: > > <import plugin="com.jcraft.jsch" version="0.1.37" match="compatible"/> > > I have eGit/jGit installed right now and I only see one copy of jsch in my > install. Since it is a small library, it wouldn't be too bad if there were > multiple copies anyway. Ah, that's a bug on our part. Our POM specific 0.1.4... sigh... We needed it for the 'Corrupted MAC on input' ssh issue. It would be nice to see in 3.7.1, however, I think we should evaluate looking at upgrading minor third party libraries during the RC cycle. Things like apache commons codec and jsch are generally low risk imho. Thanks John!
Ooops, https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5294 PW
Well, there is at least one bug concerning Jsch 0.1.41: it does not handle the new encryption scheme openssh uses to store private keys. This does affect the Egit project, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=326526. This problem is really annoying. On Linux systems, we have to find non-standard programs to generate keys Eclipse+Jsch will understand, and these keys are less secure than the one standard programs generate now.
So... it looks like this is actually fixed, but not intentionally. Both our maintenance and Juno stream builds contain jsch 0.1.44 binaries and jsch 0.1.44 source bundle. However our map file still states jsch 0.1.41. I suspect the newer version is available in some repository at build time so the builder is just grabbing the newer one already. Since we have already been running with jsch 0.1.44 for awhile, I think we can safely just update the orbit.map to refer to jsch 0.1.44 and call this done. I can make this change.
(In reply to comment #11) > So... it looks like this is actually fixed, but not intentionally. Both our > maintenance and Juno stream builds contain jsch 0.1.44 binaries and jsch 0.1.44 > source bundle. Sigh, correction it is 4.2 M4 and 4.1.2 M-build that already contain 0.1.44. However it still stands that we have been running with this for awhile in our Juno stream so I think it is worth doing in 3.x stream to be consistent. Change in master: http://git.eclipse.org/c/platform/eclipse.platform.releng.maps.git/commit/?id=1932f1dd4d2efe76b8ac5076ff260934aec4bde6 Change in R3_7_maintenance: http://git.eclipse.org/c/platform/eclipse.platform.releng.maps.git/commit/?h=R3_7_maintenance&id=4da74fadb51166d8af215267ee3d1c11be39674e
The doc options file also needs to be updated as well as the sdk build.properties. I'll take care of this in the R3_7_maintenance and master branches.
Created attachment 208330 [details] patch
Git commits http://git.eclipse.org/c/platform/eclipse.platform.releng.maps.git/commit/?id=244dc7fa3ce4d32434ec4f9544d41403172b6d43 http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=53ad91ebe088d1d3b9e37f5c9635c27eb216cb81
For reference, changes since JSch-0.1.41 (which we had in Eclipse Platform so far) are in the JSch Changelog http://www.jcraft.com/jsch/ChangeLog - The next Platform Update to JSch-0.1.45 is discussed in bug 360663 : Changes since version 0.1.43: - bugfix: hmac-md5-96 and hmac-sha1-96 are broken. FIXED. - bugfix: working around OOME in parsing broken data from the remote. FIXED. - bugfix: failed to send very long command for exec channels. FIXED. - bugfix: in some case, failed to get the response for remote port-forwarding request. FIXED. - feature: support for private keys ciphered with aes192-cbc and aes128-cbc. Changes since version 0.1.42: - bugfix: the remote window size must be in unsigned int. FIXED. - bugfix: support for EBCDIC environment. FIXED. - bugfix: data may be written to the closed channel. FIXED. - bugfix: NPE in closing channels. FIXED. - bugfix: the private key file may include garbage data before its header. FIXED. - bugfix: the session down may not be detected during the re-keying process. FIXED. - change: try keyboard-interactive auth with the given password if UserInfo is not given. - change: working around the wrong auth method list sent by some SSHD in the partial auth success. - change: working around the CPNI-957037 Plain-text Recovery Attack. - change: in searching for [host]:non-default port in known_hosts, host:22 should be also checked. - change: updating copyright messages; 2009 -> 2010 Changes since version 0.1.41: - bugfix: making exec request during re-keying process will cause the dead lock for the session. FIXED. Many thanks for PanLi at Prominic dot NET and www.prominic.net, US based hosting company. Without their testing JSch with hundreds of hosts and their bug reports, this problem was not fixed. - change: updating copyright messages; 2008 -> 2009
