> 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
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.
Buffer overruns and double frees are things you can have a high degree of confidence won't happen. Even then, the bindings to libsodium are, by necessity, unsafe, and bugs can hide there.
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.
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
> 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.
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.
> 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.
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've actually toyed around with implementing time safe operations in rust. We have the advantage that few implementations of rust exist. So in contemporary rust I can just disable inlining and introduce a function call. Not something that's safe to do in c, as far as i know. Now the compiler guys will never vouch for this behavior but once you narrow your targets things get interesting with security. Intel and Arm are both interesting platforms with a lot of quirks!
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.
> But as we all know Java has been riddled with code execution bugs.
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.
Another source of Java bugs is improper input sanitation when untrusted input eventually feed into various interpreters like embedded JavaScript or SQL. That, of cause, can happen with any language, but at least with Rust it is much harder to accidentally call into some framework that exposes an interpreter capable of arbitrary code execution.
True enough, definitely with untrusted code your surface is that much larger. What I remember from the few JVM bugs I looked at is that they were always at points where the JVM would call into the operating system or otherwise interact with native code. I would imagine Rust code might be vulnerable at those same points, though obviously much less easily.
There are basically three major classes of Java code execution bugs:
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.)
> but I wouldn't flat out claim there won't ever be an arbitrary code execution vulnerability in a Rust project.
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.
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?
Well this particular project this comment thread is about does not actually implement any cryptographic operations, those are all done by libsodium[1] a project written in C.
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.
there's some pretty great support for sodium and the like in thrussh, i think the question is whether or not that library is used correctly and what it's safety is in regards to timing attacks. This should not be a giant mystery of how safe it is. This is the file to start with https://github.com/posix4e/thrussh-snapshot/blob/master/src/...
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.
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.
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.
I found mercurial's command line to be a lower hurdle coming from previous experience with CVS and subversion. But that was several years ago and I haven't kept up with mercurial for a while.
Now I use git, and it still confuses me and I just rely on the magit frontend in emacs to do what's right.
You don't have to apologize or hedge when criticizing git (even though it seems like everyone else loves it). Just let it all out. It'll feel better :-)
>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.
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?
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.
> 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).
>Sometimes you can just tell that a project still stay fringe just by how hard it is to get to the sourceocde :(
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!"
I am male and not an English native; I simply didn't know the word. Also, for your information, it seems that WordSafety [1] (as previously appeared on HN [2]) doesn't have it in the unwanted word list; the authors may well be unaware of that meaning.
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.
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.
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.
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
Why is Scala considered "not open enough" BTW? Just curious.
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?
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