6 ms·

Although I am not against improving the safety of languages we use for system programming, the model that Rust advocates are pushing of "preventing mistakes" as

• gcp 10y ago
  Nothing prevents you from doing both approaches. I mean, while Mozilla is increasing Rust usage, they're also rolling out more extensive sandboxing. Either of those by themselves are not a good enough solution though. Just trusting on Rust means you are vulnerable to Rust bugs or logic errors. Just trusting on sandboxing means you're hoping that your trusted code (written in C/C++) doesn't have any security bugs.
  • sidlls 10y ago
    It also means trusting that the "unsafe" usage in the Rust code doesn't have any security bugs.
    • kibwen 10y ago
      Indeed, though trusting unsafe blocks in Rust is more tractable than trusting an entire C/C++ codebase due to the fact that unsafe blocks present a drastically reduced auditing surface.
      • sidlls 10y ago
        That's the contention, yes. In practice currently there is an incredible self-selection bias with respect to how tractable that position is if (when?) Rust becomes more widely used outside the circle of the True Faithful.
    • bsder 10y ago
      Sure, but the question is how wide the "unsafe" boundaries are. If I'm writing an application that uses the network in a standard way, I should be able to write a program with NO unsafe blocks. As always, things have bugs. Rust, itself, may have bugs that get exposed over time once adoption starts to increase. Rust gets some "security through obscurity" for the moment. Once they start pushing Rust code into Firefox, that will change dramatically.
      • steveklabnik 10y ago
        There's already a small amount of Rust in Firefox.
        • bsder 10y ago
          That's really cool, and I'm glad to hear it. As it expands in the Firefox codebase, it gives me the ability to tell people that "Yes, Rust is being used by lots of people".
  • deleted 10y ago
    [deleted]
• qwertyuiop924 10y ago
  #2 is up to the engineers making the product. #1 is why Rust exists: it eliminates whole classes of errors. No, it won't stop you from screwing up badly, but it just might stop the buffer overflow or race condition that would have helped a hacker steal your users' identities.
  • glandium 10y ago
    The fact that #1 is (partially) handled by the language also allows engineers to spend more time on #2.
• Jweb_Guru 10y ago
  Every systematic approach I've seen to enforcing privacy, nondisclosure, etc. and has to deal with dynamic security rules ends up having to include knowledge of information flow (via things like program counters, aka lifetimes, and in some cases explicit ownership tracking) into the language. Rust isn't enough but I think something like it will be necessary to take that next step.
• pcwalton 10y ago
  Defending against remote code execution turns out to be an excellent way to help protect your data.
• kibwen 10y ago
  > assuming that mistakes are being made Mozilla isn't using Rust as an excuse to skimp on security elsewhere. For example, Servo sandboxes tabs as you'd expect from a modern browser, despite being written in Rust from day one. Defense-in-depth is fundamental to good security, and being able to rely on the safety properties of your language adds yet another layer of defense.
• SkyMarshal 10y ago
  The name of the game for the software industry is to continually create better tools that systematically, inexorably reduce the attack surface of apps built with them. Haskell does this in an interesting way by quarantining all side-effect code into Monads and preventing data races with immutability. Rust does it by making memory errors and race conditions impossible via its ownership mechanism. Think of it as guiderails that reduce the cognitive load on the programmer by ensuring some classes of mistakes/errors/bugs simply cannot get past the compiler. Compared to C/C++, the programmer has less to think about since the compiler handles that for them. That is immensely valuable.
  • enqk 10y ago
    Nevertheless these language specific solutions are completely opaque to an end user. These are software developer centric. As an end user I cannot inspect how these were applied and therefore develop trust in the end product. There's always an element of trust at the root of running a piece of software on my machine. I wish I could quickly inspect and be sure that say, the audio engine that mozilla firefox is running runs completly in a segregated zone/container/sandbox that will prevent, even in the presence of defects, its exploitation to leak data that is important to me. I guess it's just a question of words and goals being a little bit too overlapping. Rust's approach is to address safety as in the rates of defects. However it does nothing, and probably cannot, address the security i.e. the impact on my own safety or that of my assets. As an end-user I care much more about security than I care about defects.
    • ehsanu1 10y ago
      Defects can heavily affect the security of your assets though - just preventing buffer overflow is a huge win there. It just isn't a full solution to the problem of security in general, and I don't know that any such thing could exist, whether at the programming language level or otherwise.
    • __david__ 10y ago
      > However it does nothing, and probably cannot, address the security i.e. the impact on my own safety or that of my assets. Sure it can. It actively prevents certain type of errors (buffer overflows, integer overflows), which are prime security exploits. Less exploits == more security.
• erikbye 10y ago
  Reading your comment made me think of Erlang, where the guiding principle is the opposite: large systems will contain errors, and will fail. That is what fault-tolerant is, you design your software (language, libraries and end program) in a way that will handle unforeseen errors and failures. Because in large systems there will always be bugs. http://erlang.org/download/armstrong_thesis_2003.pdf http://erlang.org/download/armstrong_thesis_2003.pdf
  • enqk 10y ago
    That does sound rather interesting! (And anti-fragile, to use a talebian neologism)
    • oldsj 10y ago
      Possibly, but is the system getting stronger on each failure(like a human muscle), or is it just recovering?
      • erikbye 10y ago
        It's resilient and fault-tolerant. Not antifragile according to Taleb's definition. Though, no reason you could not spawn 2 (or more) new processes for every 1 that crash.
  • staticassertion 10y ago
    I'm also a fan of this approach, and am currently learning Erlang because of it. However, I do not feel that the approaches are exclusive. Erlang is dynamically typed and it is robust because Actors act as isolation boundaries and are managed by supervisors. So the approach is "bugs happen, always recover". You can also use type annotations in Erlang to get "bugs happen less, always recover".
    • erikbye 10y ago
      Perhaps not mutually exclusive, all programmers try to introduce as few bugs as possible; but the philosophy is in fact "let it crash", then you reset to a stable state. Not only is the programmer unburdened of the cognitive load of trying to imagine every single point of failure, but also of the workload of a lot of defensive programming. The whole reasoning behind this is what I said before: in large systems there will always be bugs, errors and failures will happen (some even outside of your code, e.g. power failure). Imagining every point of failure is impossible, so don't try to. Don't write preemptive code. Yes, Erlang is dynamically typed, but not weakly typed.
• AsyncAwait 10y ago
  I don't get what you're saying here. - Without Rust you program to protect users assets without guaranteed memory safety. - With Rust you program to protect users assets, with the addition of guaranteed memory safety. Sounds like a win win to me.
  • enqk 10y ago
    Indeed it is a good thing. What I'm just a little bit weary of is equating that sort of improvement with increasing overall security. We went there already with Java and this hasn't stopped Java from being an attack vector. The way this sort of reasoning affects the behavior of engineers and the products they put out in front of users.
    • AsyncAwait 10y ago
      I get that you don't want developers to learn the bad habit of believing that Rust means they no longer need to pay any attention to security themselves, but that doesn't negate the fact that Rust does indeed increase some aspects of your program's security as compared to C. The security provided by Rust shouldn't be overestimated, but I think it's unfair to underestimate the benefits of the memory safety as well.
• Retra 10y ago
  It should be pretty obvious that security is not solely the responsibility of your compiler. I mean, if your OS is compromised, in can inject code into whatever you're running, whether it be rust code or not. Anyone trying to make iron-clad systems needs to understand the whole system. But if you're not trying to do that, it's nice that you don't have needless and easy-to-avoid weaknesses like those your compiler could prevent.