| Re: [egit-dev] [jgit-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.pgm/src/org/eclipse/jgit/pgm/TextBuiltin.java#238 [2] https://git.eclipse.org/r/plugins/gitiles/egit/egit/+/master/org.eclipse.egit.core/src/org/eclipse/egit/core/internal/EGitSshdSessionFactory.java
Attachment:
signature.asc
Description: Message signed with OpenPGP