3 ms·

> People do not expect the compiler to be susceptible to malware attacks I'm not familiar with D, so I'll use the example of Rust. My usual workflow looks some

> People do not expect the compiler to be susceptible to malware attacks I'm not familiar with D, so I'll use the example of Rust. My usual workflow looks something like this 1. Make some changes 2. Either use `cargo test` to run my tests or `cargo run` to run my binary. In both those cases the code is first compiled and subsequently run. I care if running that command gives me malware. I don't care at what step it happens.

daedalus_f 4y ago
Perhaps it’s about responsibility. It’s not the compilers fault if you chose to compile and run malware. But you could blame the compiler if it ran malware during the compilation process.
- iudqnolq 4y ago
  All else equal I'd agree. But I'm perplexed why people spend a lot of effort on what seems to me like a purely philosophical benefit.
  - rnk 4y ago
    It's just address part of the problem, which of course is why it seems somewhat pointless. I need to: 1. Install packages/deps/libraries etc safely 2. Run code that includes those libraries that limits their capabilities centrally.
    - WalterBright 4y ago
      > It's just address part of the problem, which of course is why it seems somewhat pointless I cut my teeth in the aviation industry, where the idea is to address every part of the problem. No one part will fix everything. Every accident is a combination of multiple failures.
  - WalterBright 4y ago
    It's not philosophical. All people who write programs that consume untrusted data should be actively trying to prevent compromise by malware.
    - iudqnolq 4y ago
      In general, I agree. I think developer tools are a special exception because there are so many gaping vulnerabilities inherent to it it's meaningless. I think of that kind of thing as the equivalent of "your laptop won't be vulnerable on odd-numbered days". That'd be a great plan if there was a pathway to going from there to no vulnerability. If that was the low-hanging fruit and you're stopping there it's a complete waste of time.
ratmice 4y ago
With rust quite often (e.g. if you are running rust_analyzer) it will run `cargo check`, to produce errors. When `cargo check` is run, build.rs compiled and run. So quite often by step 1, just opening the file in your editor before even making any changes code is compiled and run. Walter's solution here allows the compiler to be used by the editor without the editor being susceptible. Which at the very least negates the need for a pop-up in your editor asking for permission.
- iudqnolq 4y ago
  > With rust quite often ... it will run `cargo check` Yup. But making "cargo check" safe while "cargo run" stays vulnerable just reduces the number of times you run malicious code. And whether malicious code runs on my laptop every time I edit a file or every hour or every week makes absolutely no difference. One run and the malware can persist and run whenever it wants going forwards. > Which at the very least negates the need for a pop-up in your editor asking for permission. My argument is that the pop-up is security theater. I've disabled it, I don't think it should be enabled by default. [1]: I'm handwaving slightly to get from "your code depends on a malicious library" to "malicious code is run". If I recall correctly there's linker tricks that could do that, or you could just have every entrypoint call some innocuous sounding setup function that runs the malicious code.
  - ratmice 4y ago
    only if you intend to run the program though, if you want to just read the source code, perhaps to see if it contains malicious code you really don't want your editor doing such things by default, so something has to give.
deleted 4y ago
[deleted]
chlorion 4y ago
Some people try to inspect code outside of a project before including it into something. Say there is a Github repo with a crate called "totally_safe_crate", and I want to use this crate in my project, but I am not sure whether I can trust it or not. What do I do? What I would likely do is clone the repo, then open my editor and look through the source and whatnot and make my decision. In this case I never intend to run "cargo run" at all, but I may want to run an LSP server to help inspect the code, or I may accidentally enable LSP in the editor out of habit or something. In this case, it would be nice if I could be certain that simply inspecting and reading code was safe, but as it stands now, in Rust, this is not the case. We can't even inspect code to make sure it's safe unless we open the source files in a "dumb" editor. In your example you are just adding a crate to cargo.toml and firing off cargo, so of course it's not going to be useful there. Some of us may want to be more cautious than that and actually read code before putting it in our projects.

daedalus_f 4y ago

Perhaps it’s about responsibility. It’s not the compilers fault if you chose to compile and run malware. But you could blame the compiler if it ran malware during the compilation process.

iudqnolq 4y ago
All else equal I'd agree. But I'm perplexed why people spend a lot of effort on what seems to me like a purely philosophical benefit.
- rnk 4y ago
  It's just address part of the problem, which of course is why it seems somewhat pointless. I need to: 1. Install packages/deps/libraries etc safely 2. Run code that includes those libraries that limits their capabilities centrally.
  - WalterBright 4y ago
    > It's just address part of the problem, which of course is why it seems somewhat pointless I cut my teeth in the aviation industry, where the idea is to address every part of the problem. No one part will fix everything. Every accident is a combination of multiple failures.
- WalterBright 4y ago
  It's not philosophical. All people who write programs that consume untrusted data should be actively trying to prevent compromise by malware.
  - iudqnolq 4y ago
    In general, I agree. I think developer tools are a special exception because there are so many gaping vulnerabilities inherent to it it's meaningless. I think of that kind of thing as the equivalent of "your laptop won't be vulnerable on odd-numbered days". That'd be a great plan if there was a pathway to going from there to no vulnerability. If that was the low-hanging fruit and you're stopping there it's a complete waste of time.

ratmice 4y ago

With rust quite often (e.g. if you are running rust_analyzer) it will run `cargo check`, to produce errors. When `cargo check` is run, build.rs compiled and run. So quite often by step 1, just opening the file in your editor before even making any changes code is compiled and run. Walter's solution here allows the compiler to be used by the editor without the editor being susceptible. Which at the very least negates the need for a pop-up in your editor asking for permission.

iudqnolq 4y ago
> With rust quite often ... it will run `cargo check` Yup. But making "cargo check" safe while "cargo run" stays vulnerable just reduces the number of times you run malicious code. And whether malicious code runs on my laptop every time I edit a file or every hour or every week makes absolutely no difference. One run and the malware can persist and run whenever it wants going forwards. > Which at the very least negates the need for a pop-up in your editor asking for permission. My argument is that the pop-up is security theater. I've disabled it, I don't think it should be enabled by default. [1]: I'm handwaving slightly to get from "your code depends on a malicious library" to "malicious code is run". If I recall correctly there's linker tricks that could do that, or you could just have every entrypoint call some innocuous sounding setup function that runs the malicious code.
- ratmice 4y ago
  only if you intend to run the program though, if you want to just read the source code, perhaps to see if it contains malicious code you really don't want your editor doing such things by default, so something has to give.

deleted 4y ago

[deleted]

chlorion 4y ago

Some people try to inspect code outside of a project before including it into something. Say there is a Github repo with a crate called "totally_safe_crate", and I want to use this crate in my project, but I am not sure whether I can trust it or not. What do I do? What I would likely do is clone the repo, then open my editor and look through the source and whatnot and make my decision. In this case I never intend to run "cargo run" at all, but I may want to run an LSP server to help inspect the code, or I may accidentally enable LSP in the editor out of habit or something. In this case, it would be nice if I could be certain that simply inspecting and reading code was safe, but as it stands now, in Rust, this is not the case. We can't even inspect code to make sure it's safe unless we open the source files in a "dumb" editor. In your example you are just adding a crate to cargo.toml and firing off cargo, so of course it's not going to be useful there. Some of us may want to be more cautious than that and actually read code before putting it in our projects.