Of course, this doesn't protect against compiling malicious code, and then running the code. But at least I try to shut off all attempts at simply compiling the code being a vector.
I haven't heard of anyone creating a malicious source file that would take advantage of a compiler bug to insert malware, but there have been a lot of such attacks on other unsuspecting programs, like those zip bomb files.
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.
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.
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.
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.
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.
1. Install packages/deps/libraries etc safely
2. Run code that includes those libraries that limits their capabilities centrally.
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.
I'm not experienced but I thought it was normal to have some way to try out what you've written on your dev machine. Is everyone else stepping through code in their head only, and their code is run for the first time when it's deployed to production?
This way you don't need to sandbox the compiler, and it can freely use system resources and access source trees. You only need to sandbox the execution.
(As some people point out in this thread, editors are starting to use compilers to get overall meta-information, too-- if you can't even -view the code- to tell if it's malicious without getting exploited, that's bad).
If this is now only helping CI and not dev machines I don't see why it's worth the effort. Wouldn't it be much simpler and more reliable to just sandbox compilation of anything in your CI?
> if you can't even -view the code- to tell if it's malicious without getting exploited, that's bad
I guess? I can't think of a single time in my life where this would have practically helped me.
I skim dependencies on GitHub for obvious red flags and then trust them. I assume places with the resources to do actual in-depth review can disable advanced analysis in their IDEs for that.
Not really. The compiler has to be able to access large swaths of your code. You want to e.g. keep your code safe. You would have to have very finely-grained sandboxing to prevent substantive disclosure, and even then you're likely leaking information.
Note that CTFE runs as an interpreter, not native. Although there are calls to JIT it, an interpreter makes it pretty difficult to corrupt.
I've basically converted to doing all node development in docker containers with volume mounts for source, now it looks like python is going to need to be there as well, at least for stuff that pulls in any remote dependencies.
I don't disagree at all. We're building an open source sandbox for devs right now for this exact reason. Linked it in another comment.