Tags: dacaiguoguogmail/swift-nio-ssh
Tags
Clean up incorrect comments and test behaviour (apple#96) Motivation: The recently added test asserted something about the behaviour of the code that was not true: I was just holding the test wrong. Modifications: Fix the test, remove the comment. Result: Things are better now
fixes compilation warning (apple#90) Motivation: Method Channel.removeHandlers(channel: Channel) was deprecated in 2.32, we should use recommended method instead. Modifications: - Bump swift-nio version to 2.32 to ensue that new methods are available - Use new method to remove all handlers
Add support from synchronous options (apple#80) Motivation: NIO 2.27.0 added a customisation point to `Channel` to allow options to be fetched synchronously if the caller is on the appropriate event loop. Modifications: - Add synchronous options to SSHChildChannel - Promote event loop assertions to preconditions Result: Callers can fetch channel options synchronously on 'SSHChildChannel's.
Allow users to verify SSH host keys. (apple#32) Motivation: A major part of SSH is the requirement that we validate the host keys of the server when they send them to us. This is not something swift-nio-ssh has supported prior to now: we always just accepted whatever the server sent. This is obviously not good! We need to introduce another callback here. This callback wants to support asynchrony because there are a number of ways to validate host keys that cannot be done synchronously, including asking the user to visually validate that key. This is fine, we have good patterns for doing this. Unfortunately, what's new is that prior to this point we always assumed we'd emit newKeys synchronously as soon as we could, which was always on receipt of a remote message from the server. This would allow us to _also_ immediately send the session request that follows. That is no longer true! If the user is validating the server host key, we cannot send that session request, because we won't send newKeys until the user has told us they're happy. This means we need to break an assumption that's been true for a long time, namely that sending a message won't trigger the emission of more than one message. This has some ramifications in the testing. Modifications: - Update the key exchange state machine to ask a delegate to validate the server host key. - Update the connection state machine to tolerate the key exchange state machine returning a future of a message here. - Update the connection state machine to send the session request at the same time we send newKeys, which is now an arbitrary time. - Fix the tests to stop assuming that there's only one message per received message. - Tested that the key verification callback works correctly. Results: Users can validate SSH host keys using key verification callbacks. For security reasons we require the key verification callback to be provided, so updating to this release will break running code. Sorry!