Rust 1.15.1 #148
Rust 1.15.1 #148
Conversation
_posts/2017-02-08-Rust-1.15.1.md
Outdated
| feature, and the present implementation is spectacularly unsound, we decided to | ||
| go ahead and release the fix immediately, hopefully before too many codebases | ||
| pick it up - that is, we don't consider this a breaking change that requires a | ||
| careful transition, but a necessary bug fix. |
There was a problem hiding this comment.
I think citing our RFCs here is a good idea
brson
force-pushed
the
next
branch
3 times, most recently
from
8c19d43 to
44cf794
Compare
_posts/2017-02-08-Rust-1.15.1.md
Outdated
| necessary bug fix. For more about Rust's approach to ensuring stability see the | ||
| ["Stability as a Deliverable"][stab] blog post, [RFC 1122], on language | ||
| evolution, and [RFC 1105], on library evolution (curiously, RFC 1105 does not | ||
| actually contain any language allowing for library breakage due to soundness, |
_posts/2017-02-08-Rust-1.15.1.md
Outdated
| attestation that the block is correct to bolt-on theorem provers. At the moment | ||
| the Rust library team doesn't have plans to make process changes based on this | ||
| mistake, but unsafe validation in Rust will be an area of active research | ||
| forever, and we'll continue to evaluate our options. |
There was a problem hiding this comment.
So, this was where you said it felt awkward. I agree. I think maybe cutting out the ideas is better; keep it succinct.
What can we learn from this? Well, it's at least good to be reminded why we endeavored to write a safe language in the first place: writing safe code is not easy. We have some ideas for how to catch this kind of problem earlier in the development process, but we haven't made any decisions yet.
WDYT?
|
Updated with your language @steveklabnik |
|
I've updated this with an anticipated 2017-02-09 release date |
brson
force-pushed
the
next
branch
2 times, most recently
from
3788e82 to
f9370df
Compare
_posts/2017-02-09-Rust-1.15.1.md
Outdated
| more work. For mostly-Rust codebases, the practical impact of losing read-only | ||
| text sections is relatively small (since Rust's type system is its first line of | ||
| defense), but for Rust linked into other codebases the impact could be | ||
| unexpectedly quite significant. The details of the bug are not that interesting |
There was a problem hiding this comment.
I would say
The impact of not compiling with
-fPICis well-understood, so the rest of this post focuses on the soundness bug.
_posts/2017-02-09-Rust-1.15.1.md
Outdated
| So we made that change, and we're releasing a fix. In Rust we take pride in not | ||
| breaking APIs, but since this is a new, minor feature, and the present | ||
| implementation is spectacularly unsound, we decided to go ahead and release the | ||
| fix immediately, hopefully before too many codebases pick it up - that is, we |
_posts/2017-02-09-Rust-1.15.1.md
Outdated
| don't consider this a breaking change that requires a careful transition, but a | ||
| necessary bug fix. For more about Rust's approach to ensuring stability see the | ||
| ["Stability as a Deliverable"][stab] blog post, [RFC 1122], on language | ||
| evolution, and [RFC 1105], on library evolution (curiously, RFC 1105 does not |
There was a problem hiding this comment.
i am tempted to remove this parenthetical entirely
There was a problem hiding this comment.
it's pretty far in the weeds
_posts/2017-02-09-Rust-1.15.1.md
Outdated
| components of the Rust distribution were [not compiled with `-fPIC`][fpic]. The | ||
| latter results in the text section of executables being writable in some | ||
| configurations, including common Linux configurations, subverting an important | ||
| attack mitigation, and causing longer startup times by causing the linker to do |
There was a problem hiding this comment.
“causing … by causing …” sounds weird :)
|
Addressed. |
|
|
r? @steveklabnik
Don't merge.