This is an automated email from the ASF dual-hosted git repository.
gnodet pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/mina-sshd.git
The following commit(s) were added to refs/heads/master by this push:
new 93250df5b Prepare changelog for release
93250df5b is described below
commit 93250df5bcb89cb9f5ca12bf2248283480ac30b0
Author: Guillaume Nodet <[email protected]>
AuthorDate: Tue Jun 11 22:46:55 2024 +0200
Prepare changelog for release
---
CHANGES.md | 153 +----------------------------------
CHANGES.md => docs/changes/2.13.0.md | 32 +-------
2 files changed, 3 insertions(+), 182 deletions(-)
diff --git a/CHANGES.md b/CHANGES.md
index e6e60e08e..a22da481e 100644
--- a/CHANGES.md
+++ b/CHANGES.md
@@ -28,164 +28,15 @@
# [Version 2.12.0 to 2.12.1](./docs/changes/2.12.1.md)
+# [Version 2.12.1 to 2.13.0](./docs/changes/2.13.0.md)
+
# Planned for next version
## Bug Fixes
-* [GH-318](https://github.com/apache/mina-sshd/issues/318) Handle cascaded
proxy jumps
-* [GH-427](https://github.com/apache/mina-sshd/issues/427) SCP client: fix
`DefaultScpClient.upload(InputStream, ...)`
-* [GH-455](https://github.com/apache/mina-sshd/issues/455) Fix `BaseCipher`:
make sure all bytes are processed
-* [GH-461](https://github.com/apache/mina-sshd/issues/461) Fix heartbeats with
`wantReply=true`
-* [GH-470](https://github.com/apache/mina-sshd/issues/470) MontgomeryCurve:
synchronize access to KeyPairGenerator
-* [GH-489](https://github.com/apache/mina-sshd/issues/489) SFTP v3 client:
better file type determination
-* [GH-493](https://github.com/apache/mina-sshd/issues/493) Fix arcfour128 and
arcfour256 ciphers (regression in 2.2.0)
-* [GH-500](https://github.com/apache/mina-sshd/issues/500) SFTP file system:
fix memory leak on exceptions
-* [GH-504](https://github.com/apache/mina-sshd/issues/504) Pass through
failure exception to `SessionListener.sessionNegotiationEnd()`
-* [GH-509](https://github.com/apache/mina-sshd/issues/509) SFTP v[456] client:
validate attribute flags
-* [GH-510](https://github.com/apache/mina-sshd/issues/510) Fix class name in
BuiltinIoServiceFactoryFactories (regression in 2.6.0)
-
-* [PR-472](https://github.com/apache/mina-sshd/pull/472) sshd-spring-sftp: fix
client start
-* [PR-476](https://github.com/apache/mina-sshd/pull/476) Fix Android detection
-* [PR-486](https://github.com/apache/mina-sshd/pull/486) Add missing `equals`
and `hashCode` to U2F key classes
-
-
-* [SSHD-1237](https://issues.apache.org/jira/browse/SSHD-1237) Handle
keep-alive _channel_ requests
-
## New Features
-### `[email protected]` Key Exchange
-
-The key exchange method [email protected] is now available if
the Bouncy Castle library is available.
-
-This uses a post-quantum key encapsulation method (KEM) to make key exchange
future-proof against quantum attacks.
-More information can be found in IETF Memo [Secure Shell (SSH) Key Exchange
Method Using Hybrid Streamlined NTRU Prime sntrup761 and X25519 with SHA-512:
sntrup761x25519-sha512](https://www.ietf.org/archive/id/draft-josefsson-ntruprime-ssh-02.html).
-
-
-## Behavioral changes and enhancements
-
-### [GH-318](https://github.com/apache/mina-sshd/issues/318) Handle cascaded
proxy jumps
-
-Proxy jumps can be configured via host configuration entries in two ways.
First, proxies can be _chained_
-directly by specifiying several proxies in one `ProxyJump` directive:
-
-```
-Host target
-Hostname somewhere.example.org
-User some_user
-IdentityFile ~/.ssh/some_id
-ProxyJump jumphost2, jumphost1
-
-Host jumphost1
-Hostname [email protected]
-User jumphost1_user
-IdentityFile ~/.ssh/id_jumphost1
-
-Host jumphost2
-Hostname [email protected]
-User jumphost2_user
-IdentityFile ~/.ssh/id_jumphost2
-```
-
-Connecting to server `target` will first connect to `jumphost1`, then tunnel
through to `jumphost2`, and finally
-tunnel to `target`. So the full connection will be
`client`→`jumphost1`→`jumphost2`→`target`.
-
-Such proxy jump chains were already supported in Apache MINA SSHD.
-
-Newly, Apache MINA SSHD also supports _cascading_ proxy jumps, so a
configuration like
-
-```
-Host target
-Hostname somewhere.example.org
-User some_user
-IdentityFile ~/.ssh/some_id
-ProxyJump jumphost2
-
-Host jumphost1
-Hostname [email protected]
-User jumphost1_user
-IdentityFile ~/.ssh/id_jumphost1
-
-Host jumphost2
-Hostname [email protected]
-ProxyJump jumphost1
-User jumphost2_user
-IdentityFile ~/.ssh/id_jumphost2
-```
-
-also works now, and produces the same connection
`client`→`jumphost1`→`jumphost2`→`target`.
-
-It is possible to mis-configure such proxy jump cascades to have loops. (For
instance, if host `jumphost1` in
-the above example had a `ProxyJump jumphost2` directive.) To catch such
misconfigurations, Apache MINA SSHD
-imposes an upper limit on the total number of proxy jumps in a connection. An
exception is thrown if there
-are more than `CoreModuleProperties.MAX_PROXY_JUMPS` proxy jumps in a
connection. The default value of this
-property is 10. Most real uses of proxy jumps will have one or maybe two proxy
jumps only.
-
-### [GH-461](https://github.com/apache/mina-sshd/issues/461) Fix heartbeats
with `wantReply=true`
-
-The client-side heartbeat mechanism has been updated. Such heartbeats are
configured via the
-`CoreModuleProperties.HEARTBEAT_INTERVAL` property. If this interval is > 0,
heartbeats are sent to
-the server.
-
-Previously these heartbeats could also be configured with a
`CoreModuleProperties.HEARTBEAT_REPLY_WAIT`
-timeout. If the timeout was <= 0, the client would just send heartbeat
requests without expecting any
-answers. If the timeout was > 0, the client would send requests with a flag
indicating that the server
-should reply. The client would then wait for the specified duration for the
reply and would terminate
-the connection if none was received.
-
-This mechanism could cause trouble if the timeout was fairly long and the
server was slow to respond.
-A timeout longer than the interval could also delay subsequent heartbeats.
-
-The `CoreModuleProperties.HEARTBEAT_REPLY_WAIT` property is now _deprecated_.
-
-There is a new configuration property
`CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX` instead. It defines a
-limit for the number of heartbeats sent without receiving a reply before a
session is terminated. If
-the value is <= 0, the client still sends heartbeats without expecting any
reply. If the value is > 0,
-the client will request a reply from the server for each heartbeat message,
and it will
-terminate the connection if the number of unanswered heartbeats reaches
-`CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX`.
-
-This new way to configure heartbeats aligns with the OpenSSH configuration
options
-`ServerAliveInterval` and `ServerAliveCountMax`.
-
-For compatibility with older configurations that explicitly define
`CoreModuleProperties.HEARTBEAT_REPLY_WAIT`,
-the new code maps this to the new configuration (but only if
`CoreModuleProperties.HEARTBEAT_INTERVAL` > 0
-and the new property `CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX` has _not_
been set) by setting
-`CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX` to
-* `CoreModuleProperties.HEARTBEAT_REPLY_WAIT` <= 0:
`CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX = 0`
-* otherwise: `(CoreModuleProperties.HEARTBEAT_REPLY_WAIT /
CoreModuleProperties.HEARTBEAT_INTERVAL) + 1`.
-
-### [GH-468](https://github.com/apache/mina-sshd/issues/468) SFTP: validate
length of data received: must not be more than requested
-
-SFTP read operations now check the amount of data they get back. If it's more
than
-requested an exception is thrown. SFTP servers must never return more data
than the
-client requested, but it appears that there are some that do so. If property
-`SftpModuleProperties.TOLERATE_EXCESS_DATA` is set to `true`, a warning is
logged and
-such excess data is silently discarded.
-
## Potential compatibility issues
-### AES-CBC ciphers removed from server's defaults
-
-The AES-CBC ciphers `aes128-cbc`, `aes192-cbc`, and `aes256-cbc` have been
removed from the default
-list of cipher algorithms that a server proposes in the key exchange. OpenSSH
has removed these
-cipher algorithms from the server proposal in 2014, and has removed them from
the client proposal
-in 2017.
-
-The cipher implementations still exist but they are not enabled by default.
Existing code that
-explicitly sets the cipher factories is unaffected. Code that relies on the
default settings
-will newly create a server that does not support the CBC-mode ciphers. To
enable the CBC-mode
-ciphers, one can use for instance
-
-```
-SshServer server = ServerBuilder.builder()
- ...
- .cipherFactories(BuiltinFactory.setUpFactories(false,
BaseBuilder.DEFAULT_CIPHERS_PREFERENCES));
- ...
- .build();
-```
-
-For the SSH _client_, the CBC ciphers are still enabled by default to
facilitate connecting to
-legacy servers. We plan to remove the CBC ciphers from the client's defaults
in the next release.
-
## Major Code Re-factoring
diff --git a/CHANGES.md b/docs/changes/2.13.0.md
similarity index 90%
copy from CHANGES.md
copy to docs/changes/2.13.0.md
index e6e60e08e..b7996215c 100644
--- a/CHANGES.md
+++ b/docs/changes/2.13.0.md
@@ -1,34 +1,4 @@
-# [Version 2.1.0 to 2.2.0](./docs/changes/2.2.0.md)
-
-# [Version 2.2.0 to 2.3.0](./docs/changes/2.3.0.md)
-
-# [Version 2.3.0 to 2.4.0](./docs/changes/2.4.0.md)
-
-# [Version 2.4.0 to 2.5.0](./docs/changes/2.5.0.md)
-
-# [Version 2.5.0 to 2.5.1](./docs/changes/2.5.1.md)
-
-# [Version 2.5.1 to 2.6.0](./docs/changes/2.6.0.md)
-
-# [Version 2.6.0 to 2.7.0](./docs/changes/2.7.0.md)
-
-# [Version 2.7.0 to 2.8.0](./docs/changes/2.8.0.md)
-
-# [Version 2.8.0 to 2.9.0](./docs/changes/2.9.0.md)
-
-# [Version 2.9.0 to 2.9.1](./docs/changes/2.9.1.md)
-
-# [Version 2.9.1 to 2.9.2](./docs/changes/2.9.2.md)
-
-# [Version 2.9.2 to 2.10.0](./docs/changes/2.10.0.md)
-
-# [Version 2.10.0 to 2.11.0](./docs/changes/2.11.0.md)
-
-# [Version 2.11.0 to 2.12.0](./docs/changes/2.12.0.md)
-
-# [Version 2.12.0 to 2.12.1](./docs/changes/2.12.1.md)
-
-# Planned for next version
+# Introduced in 2.13.0
## Bug Fixes
