Thrussh: Portable SSH client and server library in Rust
pijul.org
pijul.org
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
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.
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.
This isn't a flippant response: I suspect most RCEs in Rust software are likely to be high-level vulnerabilities like that.
Imagine now it is possible to construct an argument to those libsodium functions that satisfies the constraints of the Rust wrappers, but still manages to crash libsodium and execute some part of the argument, which is not unheard of since libsodium is written in C and it operates on blobs of data.
Now the only mistake the implementor of thrussh has to make is to allow for that input to be passed into the rust libsodium wrapper through the protocol implementation.
If you note the OP, he expressed it in terms of "high confidence" not a "claim there won't ever be an arbitrary code execution vulnerability in a Rust project". Which would be absurd. And it's also as good as it gets: you can't avoid vulnerabilities.
Most of those are of the form "malicious code delivered as Java applet can break out of the JVM sandbox". That is, they crucially rely on running untrusted code. By contrast, the threat model here involves attackers subverting existing, trusted code. Memory safety holes in Rust overwhelmingly rely on bizarre carefully crafted code that nobody would accidentally write.
There are some exceptions: Java is affected by serialization issues along the lines of the Rails YAML vulnerability, for instance. But most of those don't apply to Rust either for various reasons.
1) Bugs in native code (generally image processing, compression, etc). This code tends to be derived from existing libraries, and so shares common vulnerabilities.
2) Bugs in sandboxing when running untrusted code. Java's sandbox model is fundamentally flawed and I don't believe it can ever be secured.
3) Executing untrusted external user input within the JVM context, e.g., by evaluating external data using your internal scripting language that has access to the JVM or relies on JVM sandboxing.
Of those:
1) Not much you can do, but issues are relatively rare.
2) Can be avoided by not running untrusted code in a JVM-enforced sandbox (applets are dead, sorry).
3) You'll be fine if you steer clear of libraries that even go near eval() of untrusted user input. The culprits here are serial offenders due to architectural/design issues, and are easy to avoid (e.g. Apache Struts.)
Also, all you need to get remote execution is bad user input validation surrounding some instance of std::process::Command.
Though such cases have been few and far between, soundness bugs have shown up in Rust, and some oddities in the way RAII works have lead to the notion of Prepooping your pants[1] to avoid use-after-free bugs.
1 - http://cglab.ca/~abeinges/blah/everyone-poops/
Rust is a phenomenal language, and one I'm placing a lot of faith in, but it provides only very specific guarantees and it's unwise to assume it will protect you from more than it actually does
There's a huge difference between checking your program for memory model violations, and checking the compiler for correctness.
Given a program written 99.9% in safe Rust, and a minimum set of unsafe stubs (trivial enough to prove) to access outside world (syscalls), you can assume you're safe against RCE. The holes are more likely in the supporting logic outside your program - kernel, dynamic loaders, network stacks, debug/trace interfaces, row hammer, etc.
> Rust is a phenomenal language, and one I'm placing a lot of faith in, but it provides only very specific guarantees and it's unwise to assume it will protect you from more than it actually does
I do agree with this point, though. It guarantees you will not escape the envelope of a specific memory model and defined behavior, up to the boundary of "unsafe" blocks, and assuming the runtime environment is not interfered with externally. You still need all those externalities to be secure, and it does nothing for leakage through side-channels.
Right - and, if the description for the project had put it in those terms, I'd have felt the project deserved more of my trust. My problem was precisely with the dismissive tone in which it says "It's written in Rust so I'm immune to all these things", while not actually backing that statement with a half-decent justification for why Rust would help.
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.
I haven't, but isn't it supposedly more friendly?
And you will need help.
Now I use git, and it still confuses me and I just rely on the magit frontend in emacs to do what's right.
To this day, I miss its fantastic cherry picking, but modern git does not have much worse usability.
What insults is the author referring to?
By contrast, the Rust community has a reputation for well-above-average friendliness.
# apt-get install darcs
$ darcs get https://pijul.org/thrussh
$ darcs get https://pijul.org/thrussh_client
$ darcs get https://pijul.org/thrussh_server darcs get https://pijul.org/thrusshTo 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?
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.
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.
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).
Not just darcs, but also the lack of ability to look at the sources online.
Yup. It's sad/ironic how many techs get frustrated by never-ending signup forms - and recognise that putting roadblocks in the way of signups is A Bad Thing - yet use non-mainstream stuff, figuring that "it's just 30 seconds to install X!"
https://blitiri.com.ar/p/darcsweb/
Example repo:
http://www.divineinvasion.net/darcsweb/darcsweb.cgi
Darcs was/is a really nice vcs and I'm kinda sad it didn't catch on more.
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?
The contents of this website are © 2016 Pierre-Étienne Meunier and Florent Becker under the terms of the GFDL 1.3 or later.
Maybe none of the authors/collaborators are native English speakers. Also thrush/candidiasis is definitely not a women's only thing.
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.
Why is Scala considered "not open enough" BTW? Just curious.
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?