You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "gnodet (via GitHub)" <gi...@apache.org> on 2024/07/26 13:27:57 UTC

[I] Plan SSHD 3.0 [mina-sshd]

gnodet opened a new issue, #564:
URL: https://github.com/apache/mina-sshd/issues/564

   ### Description
   
   SSHD could raise the target JDK runtime to JDK 17 or more.
   
   
   ### Motivation
   
   This would allow raising some dependencies:
     https://github.com/apache/mina-sshd/blob/master/.github/dependabot.yml#L25-L47
   
   ### Alternatives considered
   
   With the new JDK release train, libraries and projects have to move along in order to not be kept back on old unsupported dependencies.
   
   ### Additional context
   
   _No response_


-- 
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-unsubscribe@mina.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org


Re: [I] Plan SSHD 3.0 [mina-sshd]

Posted by "tomaswolf (via GitHub)" <gi...@apache.org>.
tomaswolf commented on issue #564:
URL: https://github.com/apache/mina-sshd/issues/564#issuecomment-2821003953

   3.0.0-SNAPSHOT now has support for client-side proxies. And japicmp reports are published automatically to https://apache.github.io/mina-sshd/ .


-- 
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-unsubscribe@mina.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org


Re: [I] Plan SSHD 3.0 [mina-sshd]

Posted by "tomaswolf (via GitHub)" <gi...@apache.org>.
tomaswolf commented on issue #564:
URL: https://github.com/apache/mina-sshd/issues/564#issuecomment-2254478276

   One more thing:
   
   - Pass on the HostConfigEntry to the created session. It needs access to it for various advanced configs (like AddKeysToAgent, to mention just one).


-- 
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-unsubscribe@mina.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org


Re: [I] Plan SSHD 3.0 [mina-sshd]

Posted by "tomaswolf (via GitHub)" <gi...@apache.org>.
tomaswolf closed issue #564: Plan SSHD 3.0
URL: https://github.com/apache/mina-sshd/issues/564


-- 
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-unsubscribe@mina.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org


Re: [I] Plan SSHD 3.0 [mina-sshd]

Posted by "tomaswolf (via GitHub)" <gi...@apache.org>.
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-unsubscribe@mina.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org


Re: [I] Plan SSHD 3.0 [mina-sshd]

Posted by "tomaswolf (via GitHub)" <gi...@apache.org>.
tomaswolf commented on issue #564:
URL: https://github.com/apache/mina-sshd/issues/564#issuecomment-2791199167

   Yes, bumping the BREE to 17 is too much for a library such as this. We can build with the newest and greatest Java version, but the BREE should stay at Java 8 for as long as it isn't EOL yet.
   
   > For 3.0.0, I have quite a few things that I'd like to do:
   
   I have started with this. Current work-in-progress is in branch `dev_3.0`. CI builds are set up, and merges into that branch will get published into the [Apache Snapshot](https://repository.apache.org/content/repositories/snapshots) maven repository (3.0.0-SNAPSHOT).
   
   > 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.
   
   This was actually already done in commit f58dfde on branch master for 2.16.0.
   
   > 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.
   
   See branch `dev_3.0`. If anyone wants to take a look, a good starting point to understand what I did is the [change notes](https://github.com/apache/mina-sshd/blob/dev_3.0/CHANGES.md) and the links given there.
   > 
   >  Implement client-side proxy protocol (SOCKS, HTTP CONNECT) as a filter that can be inserted beneath the transport layer filter.
   
   This will come next. The server-side HAProxy protocol already is there in `dev_3.0` as a filter.
   
   
   


-- 
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-unsubscribe@mina.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org


Re: [I] Plan SSHD 3.0 [mina-sshd]

Posted by "tomaswolf (via GitHub)" <gi...@apache.org>.
tomaswolf commented on issue #564:
URL: https://github.com/apache/mina-sshd/issues/564#issuecomment-3243943629

   I'm closing this. The 3.0.0 development is on-going, and this issue to plan it is no longer helpful.


-- 
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-unsubscribe@mina.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org