Earlier quoted context omitted.
This isn’t build time though really, which I agree is a moment you would expect to run arbitrary code. This is “edit time.”
It is build time. Whether rust-analyzer should run build-time code at initialization is a different discussion.
Using Rust Macros to exfiltrate secrets
71–76 of 76 posts
Re: Using Rust Macros to exfiltrate secrets
#72Earlier quoted context omitted.
It is build time. Whether rust-analyzer should run build-time code at initialization is a different discussion.
That is a more philosophical definition of build time than what I am referring to.
Rust macros and build.rs require build commands to be executed by the rust compiler (cargo check, for example).
These are third party tools that have been implemented to execute build commands during initialization. It's not an issue with Rust, it's an issue with the implementation of the language client and text editor allowing the client to initialize when opening a workspace.
Re: Using Rust Macros to exfiltrate secrets
#73I can't believe that people is comparing opening a project in a code editor with running a build script. The PoC doesn't even open a file, it just opens the directory. It's a pretty big difference, when you execute a build script you _expect_ to run code, when you open a directory in your editor you don't expect any side effect _at all_. My guess is that since the proc_macros returns a TokenStream, rust-analyzer have…
It’s just not a new problem. Bash does auto–completion on Makefiles, which requires running make and asking it what the make targets are. IDEs can and will run ./configure for you, so that it can find the right include paths. Etc, etc.
Personally, I thought everyone already knew about this. I knew that proc macros would be a risk when I first heard about rls, years ago.
Certainly editors need to confirm with the user that they are ok with starting the compiler when they load a new project, but also we need to use fine–grained security systems like SELinux that can and do prevent programs from accessing things that they’re not supposed to access.
Re: Using Rust Macros to exfiltrate secrets
#74Earlier quoted context omitted.
That's a really recent feature and I'm sure Rust-analyzer will support it soon. I suspect the same problem exists in many other languages. How can you open a CMake project without executing it?
In a text editor....
Re: Using Rust Macros to exfiltrate secrets
#75Earlier quoted context omitted.
That is a more philosophical definition of build time than what I am referring to.
It's not philosophical, it is literal. Rust macros and build.rs require build commands to be executed by the rust compiler (cargo check, for example). These are third party tools that have been implemented to execute build commands during initialization. It's not an issue with Rust, it's an issue with the implementation of the language client and text editor allowing the client to initialize when opening a workspace.
They may be spiritually or metaphorically still build steps in some sense, but they are happening outside that context.
Re: Using Rust Macros to exfiltrate secrets
#76Earlier quoted context omitted.
There are three main problems with curl | sh: the file one the web server could be replaced without modifying the source in version control (and unlike a git checkout, the hash of the file is not verified), you can’t read the code before it runs, and curl could fail to download the whole file. Of course, I bet a lot of people don’t bother to read any of the source code of a program that they’ve downloaded anyway.
Downloading a tarball and running ./configure from it (pretty dang common) also does not have the changes checked into version control, nor the hash verified. Same is true of `npm install`, deb/rpm/etc packages, etc: you don't have proof what was distributed to you matches up with what was in VCS. You can read the code before it runs and solve the "curl could fail" theoretical arguments by just.. removing `| sh` and…