tomaswolf commented on issue #564: URL: https://github.com/apache/mina-sshd/issues/564#issuecomment-2254142413
For 3.0.0, I have quite a few things that I'd like to do: * Break API big style :-) Seriously. There are a things in the list below that just cannot be done without breaking API. * Undo that awful sshd-common/sshd-core split. Instead, have sshd-common/sshd-client/sshd-server, _without split packages_. Make then all three proper OSGi bundles, and drop the sshd-osgi re-amalgamation. * A similar split might make sense on SFTP level (sshd-sftp-common/sshd-sftp-client/sshd-sftp-server). * Change the session initialization. Sessions should _not_ initiate communication in their constructor! Have an explicit `start()` method instead, and make sure it's called at an appropriate time. * Have a mechanism to configure a session after it has been instantiated, but before it starts. (Other than global properties on the SshClient!) There needs to be a simple way to configure sessions individually right after they have been created. * Refactor the SSH protocol implementation. It's a mess IMO, split over various levels of inheritance, which just feels wrong. Use composition instead. Give each session a filter chain. Implement the transport layer as a filter in that filter chain. Implement the authentication protocol as a filter atop. Implement the connection protocol atop. A callback from transportation layer to connection layer will be needed to handle getting "unsupported" replies (transport layer) to unknown global requests (connection layer). * Implement client-side proxy protocol (SOCKS, HTTP CONNECT) as a filter that can be inserted beneath the transport layer filter. * Don't require Bouncy Castle for EC keys. Java has built-in support for these even in Java 8. * Don't require net.i2p for ed25519/curve25519. It has a security flaw. Make our code work with any of Java ed25519 (since Java 15), BC ed25519, or net.i2p. (Tried already, but it's messy, and not possible without API breaks. Now that we require Java 17 for building, it would be easier to do.) * Have multi-release JARs (especially for the cipher algorithms and ed25519) * Rethink whether all the machinery for SecurityRegistrars is really needed and worth the maintenance effort. Can't we just use whatever Security providers are installed, and leave it at that? All that dynamic class loading is so fragile, and it might not always use the appropriate class loaders... (see e.g. GH issue 502) Plus umpteen little details changes that I can't enumerate all right now. Some of these ideas might need to be written down in more detail first. Do we have a wiki somewhere? (Confluence? GH wiki pages? Or collaborate in a Google doc?) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
