Re: [jgit-dev] [egit-dev] Bug 520927: moving away from JSch

["Randall S. Becker" <rsbecker@xxxxxxxxxxxxx>]

A key operability requirement, as you mentioned, is not asking for passwords
repeatedly. This problem showed up for passphrases when host case
sensitivity showed up on ~/.ssh/config. This was fixed. However, the
prompting for passphrases should be included. A mechanism for sharing
authentication is important for operability within EGit so that users of
JGit who add a separate plugin from EGit can avoid reprompting. I suggest
that this be made available. It was in JSch and would be a real pain not to
have that capability going forward.

> -----Original Message-----
> From: jgit-dev-bounces@xxxxxxxxxxx <jgit-dev-bounces@xxxxxxxxxxx> On
> Behalf Of Thomas Wolf
> Sent: November 18, 2018 15:31
> To: Dave Musicant <musicant@xxxxxxxxx>
> Cc: EGit developer discussion <egit-dev@xxxxxxxxxxx>; JGit Developers list
> <jgit-dev@xxxxxxxxxxx>
> Subject: Re: [jgit-dev] [egit-dev] Bug 520927: moving away from JSch
> 
> 
> > On 18 Nov 2018, at 20:32 , Dave Musicant <musicant@xxxxxxxxx> wrote:
> >
> > How does this relate to use of JschConfigSessionFactory and related
APIs?
> 
> The SshSessionFactory and related APIs are unchanged.
> 
> There is a new FtpChannel abstraction; you might want to migrate to that
if
> your code uses it.
> (I doubt it; the main user is probably TransportSftp inside JGit, which
has
> been adapted.)
> 
> If you want to continue using JSch, nothing changes.
> 
> > Given the numerous reported problems with JSch that I'm learning about
> from these links, should I be planning on some form of migration within my
> own source code?
> 
> New features will most probably only be integrated in the Apache MINA sshd
> code.
> JSch is a dead-end because it is unmaintained. It is for instance
impossible to
> make it support ed25519 keys without forking it, and we're not going to do
> that.
> 
> > Is there now a "ApacheMINAConfigSessionFactory" replacement?
> 
> Yes, it's called org.eclipse.jgit.transport.sshd.SshdSessionFactory.
> 
> The SshSessionFactory and related APIs are unchanged.
> 
> There is a new FtpChannel abstraction; you might want to migrate to that
if
> your code uses it.
> (I doubt it; the main user is probably TransportSftp inside JGit, which
has
> been adapted.)
> 
> If you want to continue using JSch, nothing changes.
> 
> If you want to use the new Apache MINA sshd, do two things:
> 
> 1. Include the bundle org.eclipse.jgit.ssh.apache in your dependencies.
> 
> 2. Use a org.eclipse.jgit.transport.sshd.SshdSessionFactory.
> 
> Simple usage is demonstrated by the way we use it in the JGit command-line
> tools, see [1].
> This runs with a cache to cache loaded private keys to prevent asking the
> user multiple times for passwords for the same encrypted private keys, and
> ensures the cache is cleared before the command terminates. Not perfect,
> but the best I could come up with in Java.
> 
> (As an aside: the JSch implementation caches keys on the JSch instance.)
> 
> More complex usage is demonstrated by the way EGit uses this.[2] This uses
> its own subclass of SshdSessionFactory to customize a few things:
> 
> * do not use a key cache but use a password provider for encrypted keys
that
> uses the
>   Eclipse secure storage to store and retrieve passwords for encrypted
keys.
> That way it
>   can also avoid asking the user repeatedly for the same password, but
> doesn't need to
>   cache private keys.
> * obtain proxy configuration from the Eclipse proxy preferences.
> * obtain some other preferences from the Eclipse "General->Network
> Connections->SSH2"
>   preference page.
> 
> Both use cases simply install the new factory via the already existing
> SshSessionFactory.setInstance().
> 
> If you have special requirements, subclass SshdSessionFactory to do what
> you want.
> If the current implementation is not configurable enough for your use
case,
> file a bug report with severity "enhancement". Now is still the time where
we
> can even do API-breaking changes since 5.2.0 is still not released.
(Release is
> planned for 2018-12-19.) Note that I would like *not* to expose any sshd
> interfaces through the public API of org.eclipse.jgit.ssh.apache. (The old
> JSchConfigSessionFactory did exactly that and gave you access to the
> underlying JSch object. I don't want that for the sshd integration.)
> 
> HTH,
> 
>   Thomas
> 
> [1]
>
https://git.eclipse.org/r/plugins/gitiles/jgit/jgit/+/6c14d273f/org.eclipse.
jgit.p
> gm/src/org/eclipse/jgit/pgm/TextBuiltin.java#238
> [2]
>
https://git.eclipse.org/r/plugins/gitiles/egit/egit/+/master/org.eclipse.egi
t.co
> re/src/org/eclipse/egit/core/internal/EGitSshdSessionFactory.java