23 ms·

It seems like that will change in the (near) future according to the following github issue[0]. A quote from one of the developers, rami3l, in that thread[1]:

• sestep 2y ago
  Oh sad! Dang I actually really liked the feature, it's super convenient for keeping developer environments in sync. I left a comment in that thread asking for clarification.
  • thesuperbigfrog 2y ago
    >> Oh sad! Dang I actually really liked the feature, it's super convenient for keeping developer environments in sync. I left a comment in that thread asking for clarification. Here is a slightly contrived, but realistic example of why it is a bad idea: 1) Attacker discovers vulnerability in an older version of the Rust toolchain 2) Attacker creates useful crate and helps it to get widely adopted or becomes trusted contributor to a crate that is already popular 3) Attacker creates and publishes crate changes with exploit code and rust-toolchain.toml to trigger use of older, vulnerable Rust toolchain 4) Unsuspecting developers build the trapped crate or something that depends on it and get owned Installing toolchains automatically without the user's consent or permission is a supply chain attack in waiting for both Rust and Go. Perhaps they could make it a configuration setting that developers could opt-in? That would let developers who want automatic toolchain installs to have it and others who do not want it (or whose employers will not allow it) to not have it.
    • sestep 2y ago
      Thanks, I understand this; but what I don't understand is, wouldn't it be easier for the same attacker to do the same thing by exploiting a vulnerability in a different crate, and include that other crate as a dependency? As for configuration: to me, having it be opt-in negates the entire benefit. My point is that automatically installing the correct toolchain makes it far easier to collaborate with others who aren't nearly as obsessive about Rust as I am.
      • thesuperbigfrog 2y ago
        >> wouldn't it be easier for the same attacker to do the same thing by exploiting a vulnerability in a different crate, and include that other crate as a dependency? Possibly, which is why the example is a bit contrived. In most cases, the toolchains will likely be more trusted and be on approved lists whereas binaries created by third-party crates are not. For more secure environments, explicitness is valued and automatic installation of anything is frowned upon because it can introduce unvetted changes which could include vulnerabilities. It depends on what work is being done and how much toolchains and ecosystem can be trusted.
    • icholy 2y ago
      That seems like a lot of hoops to jump through considering that rust allows arbitrary code execution during compile time anyway.
      • thesuperbigfrog 2y ago
        >> That seems like a lot of hoops to jump through considering that rust allows arbitrary code execution during compile time anyway. If you mean build.rs build scripts, yes, those do run, but it is not arbitrary code. You can view and inspect them before building. If you need more security, you can download all the dependencies and build inside an isolated container.
        • icholy 2y ago
          > but it is not arbitrary code uhh ya it is. There's also https://github.com/eleijonmarck/do-not-compile-this-code https://github.com/eleijonmarck/do-not-compile-this-code
          • thesuperbigfrog 2y ago
            No. The code in question is plainly visible in the crate: https://github.com/eleijonmarck/do-not-compile-this-code/blob/master/innocent_lib/src/lib.rs https://github.com/eleijonmarck/do-not-compile-this-code/blo... This is true for all third-party libraries. If you blindly download and execute code from the Internet, this is a risk you are assuming. As I stated above, if you need more security, you can download all the dependencies and build inside an isolated container.
            • icholy 2y ago
              [flagged]
              • dang 2y ago
                You can't post like this here, so I've banned the account. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
    • kokada 2y ago
      Author here. In Go case though the version can only go higher, not lower (e.g.: it will not download a toolchain if the Go version is set to lower than your current one, only higher). So I can't see the same attack being executed here.
      • thesuperbigfrog 2y ago
        >> In Go case though the version can only go higher, not lower That is good to know, assuming that the newer hypothetical toolchain is not vulnerable (e.g. a zero-day in the newer toolchain). My opinion is still that toolchains (newer or older) should not be implicitly installed without the developer's explicit permission. This could be a configuration setting that the developer has opted-in or a "This package requires toolchain version X. Install it? (y/n)" prompt.
        • kokada 2y ago
          > That is good to know, assuming that the newer hypothetical toolchain is not vulnerable (e.g. a zero-day in the newer toolchain). This would still be really difficult to explore: 0. An undiscovered zero-day in the newest version of Go 1. The only way to force users to use the newest toolchain is if your project has dependencies where the attacker has control, so e.g.: they can change their go.mod and set a `go` directive that upgrades to the later version 2. You need to update to this new version, because this will make Go complain that your `go` directive inside your `go.mod` is out-of-date 3. After all this, yes, Go will download the newest version of Go (that is vulnerable) But I would argue if the attacker already has 2, they have better ways to attack you (e.g.: they can add code to `init()` that will run once the module is imported, and this could be explored once you build and run the binary). Again, not saying that this is an impossible scenario, just find it highly unlikely. > This could be a configuration setting that the developer has opted-in or a "This package requires toolchain version X. Install it? (y/n)" prompt. I concur at this part though, however keep in mind that this `toolchain` feature is more akin to adding a module dependency, since it reuses the whole module system. I think there is already lots of trust that is implicit when you are managing modules, and this new feature doesn't make it worse. If anything, considering that the binaries can only come from golang.org/toolchain and I assume Go already check the checksum of every module that it downloads (and also that Go is perfectly reproducible: https://go.dev/blog/rebuild https://go.dev/blog/rebuild), if anything this is probably more trusted than a random module that you add to your project.