5 ms·

I'm gonna pimp my own complaint here: https://news.ycombinator.com/item?id=29125409 https://news.ycombinator.com/item?id=29125409 I think library permissions s

by Groxx 5y ago

I'm gonna pimp my own complaint here: https://news.ycombinator.com/item?id=29125409 https://news.ycombinator.com/item?id=29125409 I think library permissions systems would mitigate or effectively eliminate a huge amount of these, and significantly raise the cost or reduce the targets of nearly all attacks. Libraries are, in practice, treated as black boxes. I think that's largely reasonable - that's almost the whole point of leveraging someone else's work. But our languages/etc do not allow doing that in any sane way. I think that's completely ridiculous.

jiggawatts 5y ago
The one thing I like about the Rust crates ecosystem is that crates have "tags" along the lines of "nostd" and the like. That's a good idea, but it wasn't taken anywhere near far enough as a policy. The technology is like 90% there, it just needs that 10% to be super useful. For example, did you know that a "Rust" crate can be 99.999% C/C++ code? A lot of them are. Some typo squatter basically wrapped a bunch of libraries like "libpng" and whatnot. Behind the scenes, all of these "Rust crates" are invoking cc and won't even build if you're on certain Rust toolchains! There's no indication of this on crates.io. Imagine if crates were scanned automatically by something like Microsoft's Roslyn and each crate and crate version had automatic tags along the lines of "pure Rust", "Safe Rust only", "Uses only std", "processor portable" (no-CPU-specific conditional compilation), "platform portable" (no Linux/Windows conditional compilation), etc... Obviously, the transitive dependencies would then bubble up. So if a crate that says "portable" has a dependency that changes from "portable" to "Linux-specific", then the crate should lose the "portable" tag. The crates.io team would prefer that every Rust user do this themselves. Manually. For every update. Tens of thousands of people doing this work over and over. Forever. I'd like to see this done properly, once, centrally, in a controlled and hard-to-spoof way. Security is not just about memory safety.
- Groxx 5y ago
  Exactly. And raising awareness of use of these less-than-palatable practices tends to lead to a constant pressure to only use them when strictly necessary, generally leading things to a broadly safer end state. (edit: sorry, I removed the chunk about cargo-geiger: https://crates.io/crates/cargo-geiger https://crates.io/crates/cargo-geiger . tl;dr showing something like that everywhere by default would likely encourage fewer unsafe uses (ideally zero), which would usually be a good thing - there's a lot of flawed unsafe use out there. that's part of why it's unsafe.)
  - jiggawatts 5y ago
    And the Rust foundation could give out awards for projects that convert crates from unsafe to 100% safe code, etc...
    - Groxx 5y ago
      Yeah. A good number that I've run across boil down to "this coding pattern is easier with a dash of unsafe". Sometimes that's valid! But that's pretty strongly "guilty until proven innocent" in my book. Verifying it on all past and future architectures is far beyond my skill, and I suspect that's true of many of the people writing libraries that are using it too. (not all, clearly! but probably many.)
stubish 5y ago
This seems like a great idea. It doesn't even need to happen all at once. Starting with limiting what can be done by code run at compile time or editor load time would pull the teeth of the novel attacks in the article. Later, more interesting things like 'no files with unsafe code that haven't been audited' could be tackled.

by Groxx 5y ago

jiggawatts 5y ago

The one thing I like about the Rust crates ecosystem is that crates have "tags" along the lines of "nostd" and the like. That's a good idea, but it wasn't taken anywhere near far enough as a policy. The technology is like 90% there, it just needs that 10% to be super useful. For example, did you know that a "Rust" crate can be 99.999% C/C++ code? A lot of them are. Some typo squatter basically wrapped a bunch of libraries like "libpng" and whatnot. Behind the scenes, all of these "Rust crates" are invoking cc and won't even build if you're on certain Rust toolchains! There's no indication of this on crates.io. Imagine if crates were scanned automatically by something like Microsoft's Roslyn and each crate and crate version had automatic tags along the lines of "pure Rust", "Safe Rust only", "Uses only std", "processor portable" (no-CPU-specific conditional compilation), "platform portable" (no Linux/Windows conditional compilation), etc... Obviously, the transitive dependencies would then bubble up. So if a crate that says "portable" has a dependency that changes from "portable" to "Linux-specific", then the crate should lose the "portable" tag. The crates.io team would prefer that every Rust user do this themselves. Manually. For every update. Tens of thousands of people doing this work over and over. Forever. I'd like to see this done properly, once, centrally, in a controlled and hard-to-spoof way. Security is not just about memory safety.

Groxx 5y ago
Exactly. And raising awareness of use of these less-than-palatable practices tends to lead to a constant pressure to only use them when strictly necessary, generally leading things to a broadly safer end state. (edit: sorry, I removed the chunk about cargo-geiger: https://crates.io/crates/cargo-geiger https://crates.io/crates/cargo-geiger . tl;dr showing something like that everywhere by default would likely encourage fewer unsafe uses (ideally zero), which would usually be a good thing - there's a lot of flawed unsafe use out there. that's part of why it's unsafe.)
- jiggawatts 5y ago
  And the Rust foundation could give out awards for projects that convert crates from unsafe to 100% safe code, etc...
  - Groxx 5y ago
    Yeah. A good number that I've run across boil down to "this coding pattern is easier with a dash of unsafe". Sometimes that's valid! But that's pretty strongly "guilty until proven innocent" in my book. Verifying it on all past and future architectures is far beyond my skill, and I suspect that's true of many of the people writing libraries that are using it too. (not all, clearly! but probably many.)

stubish 5y ago

This seems like a great idea. It doesn't even need to happen all at once. Starting with limiting what can be done by code run at compile time or editor load time would pull the teeth of the novel attacks in the article. Later, more interesting things like 'no files with unsafe code that haven't been audited' could be tackled.