Meg (@megmac@treehouse.systems)
social.treehouse.systems
hoooooly shit the new version of serde_derive includes a pre-built executable and has no official way to turn that off? Wtaf. https://github.com/serde-rs/serde/issues/2538 #rustlang

So, serde seems to be downloading and running a binary on the system without informing the user and without any user consent. Does anyone have any background information on why this is, and how this is supposed to be a good idea?

dtolnay seems like a smart guy, so I assume there is a reason for this, but it doesn’t feel ok at all.

  • BatmanAoD@programming.dev
    10·
    11 months ago

    One problem is that the build isn’t easily reproducible: there are a few comments in that issue thread from someone trying to reproduce it and failing.

    • TehPers@beehaw.org
      71·
      11 months ago

      That seems like it could be an issue, but not the issue being raised by the post. The original post was talking about executing binary code on a user’s machine without consent. The thing is, this is how a lot of Rust packages work. Any package can have a build.rs that runs arbitrary code on a developer’s machine (that gets compiled into a binary automatically by Cargo). Any proc macro is arbitrary code that gets compiled into a binary and executed on a developer’s machine. In fact, any library, regardless of if there’s a build.rs or if it’s a proc macro, can have malicious code in it that gets executed when a developer calls a specific method.

      None of this is new. When done maliciously, it’s called a supply-chain attack. All packages can do this. This is part of why there’s been interest in executing some of this code in WASM runtimes within the compiler, so that developers can explicitly control the level of impact those packages can have on a developer’s machine. That being said, WASM doesn’t solve the fact that any package can just have malicious code in it that gets executed during runtime. This is why people should vet their packages themselves (when it’s important, at least) to ensure that this won’t happen to them.

      • BatmanAoD@programming.dev
        8·
        11 months ago

        If the executable were easily reproducible from the source code, then yes, downloading a precompiled binary would be akin to executing code in build.rs or a proc macro. The fact that it’s not makes these very different, because it makes your suggestion of “vet[ting] their packages themselves” impossible.

        • TehPers@beehaw.org
          21·
          11 months ago

          Maybe I’m missing something, but I’m not seeing where in serde we’re downloading a precompiled binary. I see a script we can execute ourselves in the repository and an alternative serde_derive that uses that executable (after we compile it), but not where the actual published package has the executable.

          It’s possible I’m missing something here though.

          • BB_C@programming.dev
            5·
            11 months ago
            bsdtar tfv ᐸ(curl -sL https://static.crates.io/crates/serde_derive/serde_derive-1.0.183.crate)

            Edit: Ogh, using ᐸ which is a replacement character because Lemmy escapes the real one. This is annoying.

            There, you will see that this file exists:

            -rwxr-xr-x  0 0      0      690320 Jul 24  2006 serde_derive-1.0.183/serde_derive-x86_64-unknown-linux-gnu

            Yes, that’s a pre-built binary in the crate source release. It’s that bad.

            • TehPers@beehaw.org
              1·
              11 months ago

              Looks like I missed that, I was checking locally but I must have been checking an outdated version of the package. I’d feel better about it if it compiled on the user’s machine, which is the impression I was getting.