This is an excellent library and has saved me a countless amount of effort versus trying to roll my own. With that being said, I’d like to help out where I can, but I am not sure where to start.

Would it be possible to create some help wanted issues, so I know where I could be helpful?

First, thanks for the kind words!

There are several things that I would like to do if I had more time (they aren’t necessarily very “fun” to do, especially the parts about cleaning up legacy code):

• That gentleman over there apparently found some bugs. I fixed one that seemed indeed very wrong, I’m not sure whether the others are extra features or actual bugs.

• Testing. Also, testing again. Writing a comprehensive test suite would be really useful.

• Compiling this on Windows is a bit nightmarish, it would be nice to explore feature-gated alternatives to OpenSSL and Libsodium, without compromising security. This doesn’t necessarily rule out pure Rust alternatives, because a library you can install and use even when prototyping is more secure than one you can’t even install.

• It’s a bit outside of scope, but building replacements for OpenSSH’s ssh, sshd, ssh-keygen and ssh-agent seem rather easy using this crate, and would increase the amount of testing this crate receives. By outside of scope, I mean that this crate must remain easily readable.

• There’s no sftp yet, it requires an extension to the SSH protocol. One of the conditions for this crate to become 1.0 is to make sure that these extensions can be implemented independently in the future, so starting with sftp seems like a reasonable goal.

• This crate has seen most versions of Tokio, and Mio before that. My main way to maintain it has so far been “update Tokio, fix 300-500 compilation errors, debug the asynchronous issues I see in 10-30 minutes of testing”. Now that async/await and Tokio are both stable, it could be helpful to go through the code and try and explain as many things as possible with comments.

Hi,

I wonder if the following points still need some help:

That gentleman over there apparently found some bugs. I fixed one that seemed indeed very wrong, I’m not sure whether the others are extra features or actual bugs.

This crate has seen most versions of Tokio, and Mio before that. My main way to maintain it has so far been “update Tokio, fix 300-500 compilation errors, debug the asynchronous issues I see in 10-30 minutes of testing”. Now that async/await and Tokio are both stable, it could be helpful to go through the code and try and explain as many things as possible with comments.

It still does! I included some of his fixes, but not all. Reviewing them (and trying to get him involved at least a little bit) would be very helpful.

What fixes did you patched? I was looking at the diffs and I couldn’t spot any (git diff).

I didn’t include them verbatim. I remember the most important thing to do is to buffer the EOF packets on a channel.

TBH, I don’t fully understand the urge to fork (especially since I’ve fixed stuff since his fork, and others have contributed too!), but what can I do?

Well, I can take a more carefully look at each commit and see what I can spot and then open a discussion here. Another thing I thought was looking into other async/parallel ssh libs (basically Python ones, which is the lang I’m more familiar with) and check what’s going on there. Perhaps see some tests too. The main concern is licensing:

1. asyncssh is Eclipse Public License 2.0
2. parallel-ssh is LGPL 2.1

IDRK how permissive those licenses are to Apache 2.0 WRT derivative work.

Don’t do that! I’m not a lawyer, but since Thrussh doesn’t have an explicit CLA, I believe it might get you in trouble.

If you want explanations about the code, feel free to ask me! A more synchronous channel is the Pijul Zulip.