
Thrussh: Portable SSH client and server library in Rust - 0xmohit
https://pijul.org/thrussh/
======
pdpi
> This means that this library will never be subject to arbitrary code
> execution, leaks of secrets, buffer overruns, double frees, etc.

This sort of blanket statement doesn't fill me with confidence. Rust can only
ensure some of those things, and putting this much faith in your (admittedly
very cool) tools Seems remarkably cavalier

~~~
pslam
I think it's fair to have a high level of confidence in freedom from arbitrary
code execution, buffer overruns, double frees, etc.

It does not, however, follow that it will be free from leaks of secrets. There
are plenty of ways to leak secrets which don't involve the program leaving its
envelope of defined behavior. No language is free from that.

~~~
tinco
Though I would love to agree with you, Java also promised to fully protect us
from arbitrary code execution. In some ways even stronger than Rust. But as we
all know Java has been riddled with code execution bugs.

Now I wouldn't dare accuse Rust developers to be as terrible at writing secure
code as the average K&R worshipper, and unlike the JVM most (all?) of Rust is
actually written in Rust I hear, but I wouldn't flat out claim there won't
ever be an arbitrary code execution vulnerability in a Rust project.

~~~
conradev
I'm actually curious now – is it possible to deliberately introduce an RCE
vulnerability into Rust code with `#![forbid(unsafe_code)]`? Has anyone done
it?

~~~
pcwalton
Sure, that's easy: just write a Rust program that spawns a root shell
connected to port 1337.

This isn't a flippant response: I suspect most RCEs in Rust software are
likely to be high-level vulnerabilities like that.

~~~
whyever
You can also use /proc to violate memory safety in safe rust.

~~~
tedunangst
[http://marc.info/?l=full-
disclosure&m=141272606521280&w=2](http://marc.info/?l=full-
disclosure&m=141272606521280&w=2)

------
fizzbatter
This is cool. If anything though, i'm more intrigued by Pijul haha.

I use Git day to day simply because it is the defacto.. but i have never
_liked_ it. I've longed for a better dvcs. Granted, i'm not sure i'll ever get
it, but seeing new attempts is always appreciated.

 _edit_ : It should be noted that in my case above, "better" simply means more
intuitive. I'm not complaining about Git either. But, it has a history of not
being intuitive.. i think we can all agree there. That's all i mean.

~~~
serge2k
Have you tried mercurial?

I haven't, but isn't it supposedly more friendly?

~~~
JoshTriplett
That reputation was developed in the early days of git, back before git added
many of the usability features it now has. Today, mercurial isn't any more or
less friendly; it's just a different model, which might or might not fit
better with anyone's particular preferences about DVCS behavior.

~~~
krupan
False. Git has improved, but Mercurial is still more friendly. The thing git
has going for it is so many people use it and there is lots of help just a
google search away.

And you will need help.

------
doomrobo
>The Rust community is exceptionally good at avoiding trolls and flamewars.
One side goal of this project is to provide a safe and sane way of using SSH
without having to read pages of insults.

What insults is the author referring to?

~~~
JoshTriplett
OpenSSH comes from the OpenBSD community, which is not known for being
friendly to new users or developers. Or to humans in general.

By contrast, the Rust community has a reputation for well-above-average
friendliness.

~~~
tedunangst
I've heard rumors it's possible to use ssh without being roasted alive.

~~~
microcolonel
It's okay, Ted, Theo can't hurt you anymore. ;-)

------
the_mitsuhiko
Sometimes you can just tell that a project still stay fringe just by how hard
it is to get to the sourceocde :(

~~~
aseipp
I assume you're referring to the bit about Darcs.

To be fair, Pijul is an in-progress version control system, and Darcs (or the
now-defunct Camp[1] project, from one of my 'predecessors' in my current job)
is probably the closest thing there is to Pijul in spirit, so it's sort of
understandable why they would choose it. The package is available from
crates.io, at least. And they plan to move to self hosting in the next release
of Pijul.

On the other hand, if the developers are reading this, something like a `fast-
export` mirror of the repositories would be very useful for people just
browsing the code. Or just any way to conveniently browse it with some syntax
highlighting.

Honestly, the bigger problem is there's no easy docs to glance at on how to
use the library, or samples, without cloning repositories. That raises the
activation effort a bit, IMO. The repository being in darcs with an
`index.html` just makes this particular point a bit worse. But just
documentation on the page would make it better, too.

And really, `darcs` is packaged in most systems, is it not? Is it that
problematic to simply install it with apt or whatever?

[1] [http://projects.haskell.org/camp/](http://projects.haskell.org/camp/)

~~~
mootothemax
>Is it that problematic to simply install it with apt or whatever?

It's the equivalent of having an extra couple of fields on a SaaS signup form.

Sure, not everyone's going to be put off; you are going to lose some people,
though.

~~~
aseipp
I mean, running `apt install` is basically a requirement to build lots of
software these days. And it's not like you're installing 500 megabytes of
libraries to depend on for compilation. It's one application for the version
control system, and that's only going to be used by developers, and not end
users. They'll always just use `crates.io`.

Besides, Pijul is going to always be using "not Git" I'm afraid - after all,
it _is_ a version control system, and they're going to dogfood it. So, given
that - I doubt this complaint will ever be seen with much weight. I mean, why
would it be? Their concern is creating Pijul, not necessarily getting dozens
of contributors or doing the GitHub thing or capitulating to Git users or
whatnot.

I do consider the lack of online source browsing and online docs a
significantly larger and more immediate barrier - but I already mentioned
that.

~~~
comex
> And it's not like you're installing 500 megabytes of libraries to depend on
> for compilation.

On source-based compilation systems like Homebrew (OS X), darcs depends on
ghc, and ghc is huge (in both disk space used and compilation time). I suppose
you could make a comparison to rustc - also huge, and a dependency in such a
system for anything written in Rust; anyone interested in using this library
is writing code in Rust, so wouldn't it be a little hypocritical to have a
problem with big dependencies?

Well, maybe. Personally I think Rust would significantly benefit from a way to
compile to _portable_ C code, for precisely this reason. (I know that this is
harder than it sounds.)

It's true that end users can just obtain the library from crates.io, though,
for purposes other than browsing (which is possible with Cargo but not
convenient).

~~~
ben0x539
I think we should lay the blame for that with source-based compilation
systems.

------
hartror
> The name comes from thrushes, a family of birds to which for instance
> blackbirds belong.

Sure, but out of context I'd be willing to bet that isn't going to be the
thing that most women think of first.

10 hours on HN and no one has pointed that out?

~~~
bananaoomarang
I'm male and my first thought was not birds.

------
equalunique
I tried to find this on GitHub and ended up on the pijul/pijul repo, noticed a
default.nix file there, and got a little excited - thinking this was developed
in part using Nix.

------
curun1r
It seems like this project would run into the same issues that the
hypothetical pure-Rust version of OpenSSL would run into. Namely, that crypto
code often needs to run in constant time, regardless of input, in order to not
be vulnerable to timing attacks. As I understand it, Rust isn't capable of
generating executables that run in constant time because of limitations in
LLVM. There seems to be an RFC [1] to enable this sort of thing, but it's over
a year old and doesn't seem to have moved much.

Is there any reason why a project like this would be immune to timing attacks
whereas an SSL implementation wouldn't? Otherwise, a project like this seems
like it's just asking for a vulnerability that's not fixable.

[1] [https://github.com/rust-lang/rfcs/issues/847](https://github.com/rust-
lang/rfcs/issues/847)

~~~
scottlamb
Is the current situation any different than with C? I'm not aware of any C
language (or gcc/clang extension) equivalent of the proposed #[constant_time]
annotation/verification.

------
Bromskloss
What is the relation between thrussh and pijul?

~~~
cm3
To be used in Pijul as a pure Rust implementation of SSH client and server.
They similarly replaced Pijul's LMDB dependency with Sanakirja[1].

[1] [http://pijul.org/sanakirja/](http://pijul.org/sanakirja/)

~~~
Bromskloss
I hadn't realised that Pijul is written in Rust! I had only read about the
theoretical side of Pijul.

~~~
cm3
Started with OCaml plus a Scala prototype but moved to Rust.

~~~
draven
I was about to ask about the motivation behind these changes in the
implementation language, but the FAQ explains it all (last question):
[http://pijul.org/faq.html](http://pijul.org/faq.html)

Why is Scala considered "not open enough" BTW? Just curious.

~~~
cm3
Oracle's control of JVM and less community democracy compared to LLVM and
rustc (what is used in Rust) may be what the mean, I suppose.

------
616c
While on the topic, how many here actually run alternative SSH systems in
their day to day?

There is so much talk of Erlang and BEAM. I was wondering, would it not be
interesting to run the Erlang SSH server and client in some personal usage and
see how it fairs?

[http://erlang.org/doc/man/ssh.html](http://erlang.org/doc/man/ssh.html)

------
alexnewman
The code is a bit tricky for me to understand. I might give it another shot
tomorrow. To be fair it's a tough problem.

