tomaswolf commented on PR #446:
URL: https://github.com/apache/mina-sshd/pull/446#issuecomment-1870636101
I find this very hard to review.
1. That reformatting should be avoided. It indicates some problem with the
configuration in your IDE or in your maven build. Please ensure that your IDE
uses the same settings as the maven build, then such spurious reformatting
should not happen.
2. There is completely unrelated stuff in this change. These things must not
be in this change at all.
- The command execution timeout looks suspicious to me. At least the
timeout for running a command should by default be zero, as it was before.
- There was some refactoring grouping together isolated variables
related to KEX (SessionCountersDetails/SessionKexDetails). Probably not needed
to implement strict KEX.
3. I don't think a custom SSH config property "UseStrictKex" is needed.
4. In fact I don't think any customization flag is needed at all. (Also not
in CoreModuleProperties.)
5. This needs tests against `OpenSSH 9.6`. A container test once that
OpenSSH version is available in some Linux repositories; until then, at least
manual testing. We do have various container tests using older OpenSSH
versions, so that bit of interoperability should already be covered.
As I understand it:
Both parties can unconditionally include the "strict kex" flag in their
KEX_INIT message. "strict kex" is active if and only if both parties announce
it in their initial KEX_INIT proposal. So both parties know whether strict kex
is active once they have received the peer's proposal. If a party concludes
that strict kex is active, it can:
- check that the receive sequence number of the peer's KEX_INIT is 1. If
not, there were earlier messages, and they disconnect.
- It does not seem necessary to actively avoid sending IGNORE/DEBUG
messages before one's own KEX_INIT. Normally that shouldn't happen anyway. If
it is needed, it could be done unconditionally (i.e., irrespective of whether
strict kex will be active).
- as long as `initialKexDone == false`, only allow KEX messages. Reception
of any other message causes the party to disconnect.
- When a party sends its own NEW_KEYS message, it resets the send sequence
number to zero after having encoded the NEW_KEYS message itself. (So basically
where it installs the new keys it also resets the message sequence counter.)
- When a party receives a NEW_KEYS message, it resets the receive sequence
number to zero after having decoded the message. (Same here: where we install
the new keys, we also reset the counter.)
Protocol-wise, this should be a fairly simple change. I would refrain from
any beautification or not strictly needed refactoring; such things can be done
in later changes once the basic modified protocol works. Probably unit tests
would be the bulk of the change.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
