5 ms·

Totally reasonable stance, in my opinion, since Rust moves quickly and formalizing things takes time. But what is the stance on soundness bugs? Are they sometim

Totally reasonable stance, in my opinion, since Rust moves quickly and formalizing things takes time. But what is the stance on soundness bugs? Are they sometimes acceptable as permanent parts of the language, or is it a goal to eventually fix any soundness bugs that show up?

steveklabnik 7y ago
Soundness bugs are the only thing we make an exception in our stability policy for. In general, unsoundness is treated as a serious issue. However, "unsoundness" can mean a few different things; in the "semantics of the language" sense, they're taken very seriously. In the "there's a compiler bug" sense, they're taken seriously, but in accordance with how likely they are to affect end users, and how much work they are to fix. For example, an incorrect type signature in the standard library was fixed one day after release by changing it to the correct one and re-releasing; an issue where casting between floating points and integers causes some problems has still not been fixed, because it partially has to do with LLVM's semantics combined with our semantics, and it's not clear how to do the right thing while not seriously regressing performance. (That being said that particular issue has had a flurry of activity in the past week...) The GitHub label for these bugs is A-Unsound, which has the description "A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness" https://en.wikipedia.org/wiki/Soundness".
- mauricioc 7y ago
  Compiler bugs are not what I had in mind, so this answer is very reassuring! The original thread led me to believe this was not an absolute, official policy of the Rust project, but I am happy to hear it is.
  - steveklabnik 7y ago
    For more details, here's the written part of this: https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md#soundness-changes https://github.com/rust-lang/rfcs/blob/master/text/1122-lang... Please note that threads on internals are able to be posted to by anyone; things expressed there may not represent the way that the team feels about things.
Narishma 7y ago
I believe soundness bug fixes are the only things allowed to break backwards compatibility in Rust.
devit 7y ago
Not sure about the exact official stance, but can't imagine it's anything other than eventually fixing all soundness bugs, at least as long as someone is willing to do the work. However, an important thing to note is that Rust strives to be safe only against unintentional bugs, and not against intentional malicious code (against which you are supposed to use OS/CPU-level sandboxing), so unsoundness issues that are very unlikely to be accidentally triggered aren't necessarily a very high priority. This is a reasonable policy, since current Rust does not have a certified provably correct compiler and Rust programs in current practice don't come with formal proofs, so full provable soundness in type system doesn't really translate to any useful properties, since programs can intentionally fail to do what they are supposed to do in other ways (just do something safe but malicious or incorrect or exploit bugs in rustc or LLVM). For instance, this issue is very unlikely to be triggered by non-malicious code, so emergency action to fix it is not being taken, and instead it will probably be fixed only once there is clear consensus on the best fix.
- zozbot234 7y ago
  The line between "unintentional" bugs and "intentional/malicious" escape hatches is quite fuzzy given the extent that most Rust projects rely on outside code. Soundness bugs, at least in stable rust, are serious and should be addressed as such, or Rust developers will end up with a leftpad situation as soon as a popular third-party crate 'unintentionally' introduces some sort of soundness concern.
  - devit 7y ago
    Third party crates can include malicious safe code that doesn't exploit any soundness bugs, so I'm not sure how exploiting soundness bugs could make the situation worse. It's only a problem if you try to restrict I/O APIs and use the Rust type system as a security boundary, which is something that I don't think anyone does and that should not be done since the surface area is too vast to secure without formal proofs of the whole Rust stack, which are too time-consuming to produce with current technologies.
    - 7y ago

steveklabnik 7y ago

Soundness bugs are the only thing we make an exception in our stability policy for. In general, unsoundness is treated as a serious issue. However, "unsoundness" can mean a few different things; in the "semantics of the language" sense, they're taken very seriously. In the "there's a compiler bug" sense, they're taken seriously, but in accordance with how likely they are to affect end users, and how much work they are to fix. For example, an incorrect type signature in the standard library was fixed one day after release by changing it to the correct one and re-releasing; an issue where casting between floating points and integers causes some problems has still not been fixed, because it partially has to do with LLVM's semantics combined with our semantics, and it's not clear how to do the right thing while not seriously regressing performance. (That being said that particular issue has had a flurry of activity in the past week...) The GitHub label for these bugs is A-Unsound, which has the description "A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness" https://en.wikipedia.org/wiki/Soundness".

mauricioc 7y ago
Compiler bugs are not what I had in mind, so this answer is very reassuring! The original thread led me to believe this was not an absolute, official policy of the Rust project, but I am happy to hear it is.
- steveklabnik 7y ago
  For more details, here's the written part of this: https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md#soundness-changes https://github.com/rust-lang/rfcs/blob/master/text/1122-lang... Please note that threads on internals are able to be posted to by anyone; things expressed there may not represent the way that the team feels about things.

Narishma 7y ago

I believe soundness bug fixes are the only things allowed to break backwards compatibility in Rust.

devit 7y ago

Not sure about the exact official stance, but can't imagine it's anything other than eventually fixing all soundness bugs, at least as long as someone is willing to do the work. However, an important thing to note is that Rust strives to be safe only against unintentional bugs, and not against intentional malicious code (against which you are supposed to use OS/CPU-level sandboxing), so unsoundness issues that are very unlikely to be accidentally triggered aren't necessarily a very high priority. This is a reasonable policy, since current Rust does not have a certified provably correct compiler and Rust programs in current practice don't come with formal proofs, so full provable soundness in type system doesn't really translate to any useful properties, since programs can intentionally fail to do what they are supposed to do in other ways (just do something safe but malicious or incorrect or exploit bugs in rustc or LLVM). For instance, this issue is very unlikely to be triggered by non-malicious code, so emergency action to fix it is not being taken, and instead it will probably be fixed only once there is clear consensus on the best fix.

zozbot234 7y ago
The line between "unintentional" bugs and "intentional/malicious" escape hatches is quite fuzzy given the extent that most Rust projects rely on outside code. Soundness bugs, at least in stable rust, are serious and should be addressed as such, or Rust developers will end up with a leftpad situation as soon as a popular third-party crate 'unintentionally' introduces some sort of soundness concern.
- devit 7y ago
  Third party crates can include malicious safe code that doesn't exploit any soundness bugs, so I'm not sure how exploiting soundness bugs could make the situation worse. It's only a problem if you try to restrict I/O APIs and use the Rust type system as a security boundary, which is something that I don't think anyone does and that should not be done since the surface area is too vast to secure without formal proofs of the whole Rust stack, which are too time-consuming to produce with current technologies.
  - 7y ago