[Karellen]

I think the main problem the OP has is:

> When the do_not_compile_this_code is opened in VS Code with the rust-analyzer plugin, the editor expands the some_macro!() macro. This macro reads then content of ~/.ssh/id_rsa_do_not_try_this_at_home and deletes the file.

The rust-analyzer plugin seems to be the problem. It tries to compile the code when all you might want to do is read it. Like auto-executing Office macros.

Reading code should be a safe action. If just opening and displaying code can cause your editor/IDE to perform ACE, that's a problem.

> This behavior also occurs when cargo build is run or when the application is run.

This seems like more of an afterthought. Yes, when the application is run, whatever code is in the application is run. That's kind of the point.

And yes, you could always put arbitrary commands in your `configure` script or your `makefile`. But those commands shouldn't be run when all you did is open the file in vi(m)/emacs.

Note that vi(m), emacs, and other editors do allow files to modify the editor's environment, e.g. with modelines, or some other more advanced systems (ctags?). But they're very careful to limit the scope of what the files can do - and haven't always got it correct and the rules have needed to be tightened a few times IIRC.

So, yeah, I think this is a real issue that probably needs addressing.

[Hello71]

>> When the do_not_compile_this_code is opened in VS Code with the rust-analyzer plugin, the editor expands the some_macro!() macro. This macro reads then content of ~/.ssh/id_rsa_do_not_try_this_at_home and deletes the file.

> The rust-analyzer plugin seems to be the problem. It tries to compile the code when all you might want to do is read it. Like auto-executing Office macros.

which is why before starting extensions, VS Code pops up a warning and requires you to click not just "Agree", but "Yes, I trust the authors; Trust folder and enable all features" in a dialog that also says "Code provides features that may automatically execute files in this folder.": https://code.visualstudio.com/docs/editor/workspace-trust. while I have a lot of complaints about VS Code (including, for example, last I checked they don't have such a dialog for telemetry collection), this doesn't sound like a real exploit unless the author found some way to bypass this setting.

[dureuill]

> When the do_not_compile_this_code is opened in VS Code with the rust-analyzer plugin, the editor expands the some_macro!() macro. This macro reads then content of ~/.ssh/id_rsa_do_not_try_this_at_home and deletes the file.

Is that true though? I think I remember that by default vscode won't enable extensions like rust analyzer when opening a folder, unless you confirm that you trust the code in that folder first. Seems like reading code from the internet to ascertain it is not malevolent is a good use case for not trusting the code.

[skissane]

> And yes, you could always put arbitrary commands in your `configure` script or your `makefile`. But those commands shouldn't be run when all you did is open the file in vi(m)/emacs.

IIRC, if I open a Gradle project in IntelliJ IDEA, it executes the Gradle build script, including any arbitrary code therein. I think many other IDEs work similarly.

[Diggsey]

This doesn't actually happen though. First, VS Code asks you if you trust the workspace, and only when you answer "yes" does it run rust-analyzer.

[Grimburger]

> But those commands shouldn't be run when all you did is open the file in vi(m)/emacs.

How does a language server work without compiling the source? I don't see how this is rust specific at all.

Just turn rustanalyzer off by default if you don't want it to run on start-up. It's one click to do so.

The GP comment is completely correct, none of this needed macro expansion, it could be one line in a build.rs script.

[Karellen]

> How does a language server work without compiling the source?

That's a good point.

I might suggest that for many older languages, the work of a language server didn't need to fully compile the source code to be effective. They could probably get "good enough" results with tokenisation and lexical/syntax analysis on a file-by-file basis, cross-referencing unresolved symbols with those found in other files in the same directory (and subdirectories?), and maybe knowing something about the locations/contents of standard libraries or other system-installed libs. If the language server can't find an include file, it has the option of ignoring it, and if it comes across a symbol it can't resolve, it can just not provide any help for that symbol.

If the only "macro" expansion that's available is textual substitution (e.g. C's preprocessor), then performing that step can't do anything except provide different source code to be analysed, and is no less safe than analysing any other source code file.

Even C++'s template expansion, while Turing-complete, I don't think it's capable of performing arbitrary I/O. IIRC it's only capable of manipulating existing C++ AST fragments?

If macro expansion can execute arbitrary code though... that's a whole different ball game. It seems like the kind of thing that really should be sandboxed. Or require a specific opt-in for each new project - like the "hey, are you sure you want to run the macros in this Word doc? It may have come from an untrustworthy source." prompt (or whatever it actually says).

Edit - looking at other comments written since I started writing this reply, you do get a "are you sure you want to trust this project?" prompt. So there's that, at least.

[GrayShade]

> the work of a language server didn't need to fully compile the source code to be effective

And you can get that by toggling three settings in your LSP client. They're even documented in the user manual [0].

They are enabled by default because users won't be happy if their proc macros don't work. They'd be even less happy with the "ctags for Rust" approach you're suggesting.

[0] https://rust-analyzer.github.io/manual.html#security

[alkonaut]

Opening code in an IDE is likely compiling the code, not merely reading it. I would not expect opening a file read only in a text editor to be certain to not execute anything. That's the reason many complex editors (including vscode) these days will ask you if you trust the contents. It's likely possible to merely "open" the code "as a text editor" would, but I'm not sure if that's what happens if you answer no.

[Nanana909]

The only way to “address” it though is individual:

If you don’t want arbitrary code running on your system, you can’t use tools that require running arbitrary code.

[charrondev]

To be clear and as many other commenters have stated, VSCode and Rust Analyzer do not require running arbitrary code to view the code with basic syntax highlighting.

When you open a directory for the first time it will pop up a bit blocking dialogue asking if you trust the authors of the contents of that of the directory to allow code execution of it.

[moomin]

Suspect the same may be true of code generators in C#. It’s probably possible to do similar to Clojure as well.