Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust 1.0: Status report and final timeline

blog.rust-lang.org

Post reply on HN
Print view View original

71–80 of 128 posts

Re: Rust 1.0: Status report and final timeline

#71

Post by aturon »

comex wrote: post #61
yuriks wrote: post #27

Earlier quoted context omitted.

What was deprecated is the explicit closure type specification, which is only the ":" part.

Right. IIRC, now your choices are, roughly: |args| expr // upvars captured by reference, can't be called after function has gone out of scope move |args| expr // upvars moved from function to the closure context (or copied if trivially copyable) This is simple and good enough for most use cases. If you want more complex schemes, you have to implement them manually, e.g. to reference count the upvars, like Apple block…

That's not quite right. In the non-move case, the capture is inferred per upvar. See my other comment for details (https://news.ycombinator.com/item?id=9047766)

Re: Rust 1.0: Status report and final timeline

#72

Post by pslam »

AlyssaRowan wrote: post #22

Rust looks interesting. One thing I'm not clear on it if can do, and that I'm interested in, is secure destructors. Say I'm handling crypto, and I'm carting around an ephemeral key. When this goes out of scope, I definitely no matter what, want this zeroised by its destructor - as opposed to just having it (or a temporary copy made by a compiler optimisation!) zombling around the heap, stack or forgotten unused xmm r…

This keeps coming up, but I think it's a very, very bad idea. It's false security.

If you are running in an environment where you don't trust code running in the same compartment/sandbox/process, then it's futile to zero out memory. The caller could have prepared things such that the memset doesn't work, if the key material went somewhere else.

If you ever find yourself thinking you need to do this, what you instead need is a helper process who's only purpose is to do primitive operations with sensitive key material.

Particularly as Rust is already a "safe" language - it doesn't even make sense to zero memory which by definition another piece of code can't access. Unless there's declared "unsafe" code lying around, but you wouldn't put that in the same process, would you? At which point, what are you even protecting against? If an in-process threat is that advanced, then you're not achieving anything.

Re: Rust 1.0: Status report and final timeline

#73

Post by Gankro »

codys wrote: post #10
netcraft wrote: post #6

From the outside looking in, I am mostly impressed with the governance structure of the whole endeavor. It seems to me that it is a great model for other open source projects. Edit: as someone involved with other, less mature (and less ambitious) open source projects, if you know of pain points in the governance of rust, i'd be interested in learning about them.

There's a governance structure? That's news to me. I was under the impression that a few primary contributors (mostly/all mozilla employees?) are gatekeepers to merging anything. Having an "RFC" issue tracker isn't the same as having a governance structure. Edit: I suppose you could call the above a 'governance structure', but I'm having a hard time seeing anything impressive/different about it from other open source…

In addition to what aturon said, for actual patches these are the people who decide on merging: https://github.com/orgs/rust-lang/teams/rust-push

Maybe a third to a half are Mozilla employees (although it's infamously hard to tell who actually works at Mozilla and is just weirdly into maintaining Rust).

Re: Rust 1.0: Status report and final timeline

#74

Post by kibwen »

alextgordon wrote: post #70
pcwalton wrote: post #17

Earlier quoted context omitted.

The natural thing to want in a C-like syntax is the "arrow function" closure syntax (like ES6 or C#), but that required too much lookahead to parse. Having a keyword discourages functional style, which would be a shame in a language with a powerful iterator library. So Rust went with the Ruby/Smalltalk-style bars, which are nice, concise, and easy to parse.

It seems like the human parser should be given priority over the computer parser, when considering what is easy and what is hard. The machines work for us!

This human parser happens to prefer Rust's closure syntax to any other language's. :) Well, for usage, anyway... the written-out type of a closure for use in function signatures is not nearly as concise.

Re: Rust 1.0: Status report and final timeline

#75

Post by duaneb »

pslam wrote: post #72
AlyssaRowan wrote: post #22

Rust looks interesting. One thing I'm not clear on it if can do, and that I'm interested in, is secure destructors. Say I'm handling crypto, and I'm carting around an ephemeral key. When this goes out of scope, I definitely no matter what, want this zeroised by its destructor - as opposed to just having it (or a temporary copy made by a compiler optimisation!) zombling around the heap, stack or forgotten unused xmm r…

This keeps coming up, but I think it's a very, very bad idea . It's false security. If you are running in an environment where you don't trust code running in the same compartment/sandbox/process, then it's futile to zero out memory. The caller could have prepared things such that the memset doesn't work, if the key material went somewhere else. If you ever find yourself thinking you need to do this, what you instead…

Well, heartbleeed is a fiasco that would have been avoided by this—a vulnerability that rust shares without these secure destructors.

Re: Rust 1.0: Status report and final timeline

#76

Post by SolarNet »

pslam wrote: post #72
AlyssaRowan wrote: post #22

Rust looks interesting. One thing I'm not clear on it if can do, and that I'm interested in, is secure destructors. Say I'm handling crypto, and I'm carting around an ephemeral key. When this goes out of scope, I definitely no matter what, want this zeroised by its destructor - as opposed to just having it (or a temporary copy made by a compiler optimisation!) zombling around the heap, stack or forgotten unused xmm r…

This keeps coming up, but I think it's a very, very bad idea . It's false security. If you are running in an environment where you don't trust code running in the same compartment/sandbox/process, then it's futile to zero out memory. The caller could have prepared things such that the memset doesn't work, if the key material went somewhere else. If you ever find yourself thinking you need to do this, what you instead…

You are confusing mitigation with security.

Zeroing out memory after use is mitigation against security flaws like heart bleed. It's not a security feature in it self. Although you are right that the secure process is probably just the better solution anyway.

It's sort of like the arguments for DRM. Of course pirates will always break it, but we can still mitigate it in a number of ways.

Re: Rust 1.0: Status report and final timeline

#77

Post by mbrubeck »

duaneb wrote: post #75
pslam wrote: post #72

Earlier quoted context omitted.

This keeps coming up, but I think it's a very, very bad idea . It's false security. If you are running in an environment where you don't trust code running in the same compartment/sandbox/process, then it's futile to zero out memory. The caller could have prepared things such that the memset doesn't work, if the key material went somewhere else. If you ever find yourself thinking you need to do this, what you instead…

Well, heartbleeed is a fiasco that would have been avoided by this—a vulnerability that rust shares without these secure destructors.

No, it wouldn't. For example, the "Heartbleed in Rust" blog post [1] re-used a buffer without freeing it. No destructor runs in between the two uses, so a zeroing destructor could not possibly prevent the bug.

Maybe zeroing destructors make sense as defense-in-depth, but I don't see how they can fix a Heartbleed-style exploit in Rust. In code where the buffer is freed and its destructor runs, Rust's memory safety guarantees already prevent it from being accessed after free. In vulnerable code that just uses the same buffer twice, the destructor never has a chance to run so its behavior doesn't matter.

The real Heartbleed vulnerability (CVE-2014-0160 in OpenSSL) involved reading into uninitialized memory in a newly-allocated buffer, which safe Rust code already prevents [2].

[1]: http://www.tedunangst.com/flak/post/heartbleed-in-rust

[2]: https://news.ycombinator.com/item?id=8984169

Re: Rust 1.0: Status report and final timeline

#78

Post by mrec »

haberman wrote: post #37

I saw that integer overflow has been revised: it now defaults to checking overflow in unoptimized builds. I got a little nervous about this when reading the performance-related objections of @thestinger here: https://github.com/rust-lang/rfcs/pull/560 At least optimized builds aren't affected, but it sounds like lots of code (including Rust nightlies) aren't built optimized.

There's a discussion going on right now about whether the Rust compiler should optimize by default:

http://internals.rust-lang.org/t/optimizing-by-default/1532

Re: Rust 1.0: Status report and final timeline

#79

Post by kibwen »

cygx wrote: post #65
q2 wrote: post #25

Is it possible to estimate the amount of manpower and time required to develop a new language from scratch till it is stable and reasonably production ready? Adoption of language is different topic, since it depends on users. Rust and Go are two reasonably new languages. I understand scope and priorities of each language may be different but my idea is to get some approximation/thumb rule for any one before starting…

How did you come up with the 2 years figure for Rust? If I remember correctly, development started 2006-ish as a one-man private project.

Although Graydon did begin playing around with ideas for a programming language in 2006, very little of that language survives beyond the general philosophy of "as fast as C++, but memory-safe and with modern features". There are enormous swaths of the language that are totally unrecognizable if you go back beyond 2012 or so (which is when I personally think "modern" Rust began to emerge). This is about when the borrow checker first appeared, which eventually became the core feature that much of the rest of the language came to be designed around. That said, it still took a lot of iterations on the borrow checker to arrive where we are today.

Re: Rust 1.0: Status report and final timeline

#80

Post by pslam »

mbrubeck wrote: post #77
duaneb wrote: post #75

Earlier quoted context omitted.

Well, heartbleeed is a fiasco that would have been avoided by this—a vulnerability that rust shares without these secure destructors.

No, it wouldn't. For example, the "Heartbleed in Rust" blog post [1] re-used a buffer without freeing it. No destructor runs in between the two uses, so a zeroing destructor could not possibly prevent the bug. Maybe zeroing destructors make sense as defense-in-depth, but I don't see how they can fix a Heartbleed-style exploit in Rust. In code where the buffer is freed and its destructor runs, Rust's memory safety gua…

Thanks - that's a good example of what I was trying to convey.

The point is Rust already provides safety guarantees. If you don't trust the runtime, then why would you trust the built-in zero'ing? I get the "defense in depth" argument, but it feels a bit like doing this:

    {
      int a = secret;  // Get secret.
      assert(a == secret);  // Check "a" is actually that.
      a = 0;  // Ensure "a" is zero'd on exit.
      assert(a == 0);  // Just because.
    }
And yes, I get that you can build this into the language so it's not quite as ridiculous - you actually wipe tainted stack, for example.

But the point is: the runtime has an ABI and a machine model. Information is allowed to leak across function boundaries, beacuse it doesn't matter. Without using the "unsafe" keyword, there are no methods of getting around the machine model and dipping into the underlying actual machine.

Even if you don't have a "safe" language and runtime, it's still of limited value. It protects against threats involving data or control flow corruption after key usage, and where there isn't sufficient control of the program to perturb the secret-consuming functions. That's more of an annoyance than prevention. On the other hand, it gave the programmer a false sense that it was properly wiping secrets.

Post reply on HN