Live data from Hacker News

Using Rust Macros to exfiltrate secrets

github.com

71–76 of 76 posts

Re: Using Rust Macros to exfiltrate secrets

#71
post #34
post #24

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.

That is a more philosophical definition of build time than what I am referring to.

Re: Using Rust Macros to exfiltrate secrets

#72
post #71
post #34

Earlier 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.

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.

Re: Using Rust Macros to exfiltrate secrets

#73
post #19

I 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…

More specifically, a proc macro is a Rust function that is compiled and run inside the compiler at build time. With IDEs, LSP and other protocols for having your editor query the compiler (or language runtime, like SLIME/SWANK), the compiler now runs whenever you open your editor.

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

#74

Earlier 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....

You can do that with Rust too if you want to live like it's still the 70s.

Re: Using Rust Macros to exfiltrate secrets

#75
post #72
post #71

Earlier 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.

What I mean is that my definition of build time is more things that happen when you are running a build. If you do build time things at other times then I don’t personally consider them build time activities any more. You have converted your build time activities into something more general at that point.

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

#76
post #28
post #12

Earlier 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…

Debian are working on reproduceable builds for apt. Not there yet but going in the right direction.

https://wiki.debian.org/ReproducibleBuilds

Post reply on HN