5 ms·

This is unfair. AFL support for Rust is in fact better than that for gcc because Rust at least provides a plugin interface that doesn't require you to have it

This is unfair. AFL support for Rust is in fact better than that for gcc because Rust at least provides a plugin interface that doesn't require you to have its sources lying around -- the GCC support instruments the assembly instead of compiler IR, which is far less effective. Rust nightly at least has proper afl support, gcc doesn't. It works for clang because llvm plugins in clang are stable, but we could get there easily -- in fact stabilizing something akin to `-Xclang` is probably something that could be done in Rust today without issue. A stable version of afl-rs could exist that does the same thing gcc does, as I mentioned below. As far as compiler tools are concerned, I'm mostly okay with stuff being nightly-only. These dependencies do not pollute the dependency graph and are something you only deal with locally.

pjmlp 10y ago
Every time someone posts a cool Rust library, most of the time it makes use of nightly. How come can I advocate Rust to serious enterprise customers, if I have to justify using nightlies to make use of such tooling? Apparently downvoting every time someone mentions the issue with nightly being required is fair.
- Eerie 10y ago
  You can write your own code in stable Rust while using tooling that works on nightly. Rustup.rs makes it very easy to switch between stable and nightly.
  - pjmlp 10y ago
    Assuming you are allowed control over the development environment, which isn't possible in many companies.
    - kouteiheika 10y ago
      Fortunately for Rust that's not an issue since you don't need any special privileges to install it; hell, it doesn't even have to be installed. As long as you point your $PATH to Rust's bin directory you can use it, as far as I know.
    - nemaar 10y ago
      If you work for a company that does not let you choose your compiler then I guess they probably will be stuck with a language more mainstream anyway. I doubt that the nightly compiler will be the dealbreaker.
      - pjmlp 10y ago
        On this companies using less mainstream languages like Swift, Go, F#, Haskell, OCaml isn't an issue because the communities don't depend on having nightlies installed.
- Manishearth 10y ago
  > Every time someone posts a cool Rust library, most of the time it makes use of nightly. Examples? Examples that aren't tools, that is. The main example I can think of is serde, and that works on stable (just works better on nightly). What's wrong with nightly for using tooling? You don't have to keep updating, you can pin to a nightly from a particular date. You can use rustup.rs to switch to stable locally if you need to. I said it's unfair, because gcc has worse issues here, and everyone probably agrees that gcc is "enterprise ready".
  - pjmlp 10y ago
    Many companies let their IT control what toolchains one is allowed to use. Usually it is set in stone and only updated every few IT upgrade cycles. What the devs get on their machines is that and nothing more.
    - Manishearth 10y ago
      Good, install rustup.rs, with one date-pinned nightly, and stable. Freeze the rustup.rs install directory. Done?
      - yazaddaruvala 10y ago
        Lol, you're joking right? With respect, the Rust community is extremely in-exposed to the majority of actual enterprise environments, and that's ok. Honestly the best path forward is to just acknowledge it, say "we are working on it" and you'll get your point across better. Again with respect, because you all do really amazing work, fighting it honestly makes you and the whole community come across ignorant.
        Manishearth 10y ago
        I'm not joking. Did you miss the part where I said the situation is worse for gcc? I do understand that this is a problem. I also do understand that it is not specific to Rust. Besides, convincing IT to allow rustup with an access-controlled toolchain directory shouldn't be a big deal in many cases. If they allowed one compiler, why not two? (Rustup can also be installed without sudo/admin, but I assume you are talking about situations where they want to restrict the executables running, not just globally installed executables). Yes, I know that in some cases they may not want two, but again, in those cases the GCC solution won't work either. Note that tools like nvm etc are also quite necessary in their respective spheres for serious development. I was once in a situation where I couldn't even install node at a modern version without nvm. For clippy, we are working on it, yes. For afl a simple fix exists (write the analog of -Xclang) but that fix will only work nicely if we ship llvm headers too which clang does (which we can, but it is a decision that can't be taken lightly). So no, we are not working on it. It is an interesting idea, and I will ping the relevant people (there are plans to ship "optional components" that you can obtain with rustup or download directly), but there are no concrete plans. The general evolution of Rust is towards everything being done through rustup. If you want to install a cross compile toolchain, clippy, get stdlib sources, or a different compiler version, use rustup. All the solutions to the nightly problem involve rustup. I.e. instead of installing nightly and using clippy, you just `rustup install clippy` or something and the relevant clippy binary (or compatible source?) will be downloaded, one which will work even if you are on stable. Basically, rustup will be the thing you install when you want to use rust. This is good, but as far as enterprise is concerned, you are still installing rustup, not rust. I'm not really sure what's wrong with this, but I'm sure some enterprise shops will have issues with this. For those which don't; the solution of having nightly installed via rustup in a frozen directory is not that much different, just unweildy. I have worked in places where the computer is locked down for many teams. But not in a place where it would be locked down in a way that rustc would be okay but rustup would not. I'd love to hear more about such cases and discuss how it can be addressed, but I'd prefer email (username@gmail or @mozilla.com). Thanks :)
- frewsxcv 10y ago
  In this particular instance, there's no reason to be shipping afl.rs in production code. It's just a tool that's meant for local development, testing environments, or maybe even part of a CI workflow.
- wyldfire 10y ago
  I think this is a legit complaint. I think I understand why the rust team wants folks to use nightlies for unstable features. But if you had to opt-in with special cargo/compiler flags then it would probably be sufficient.
  - Manishearth 10y ago
    (Such a flag exists as an environment var, but you're not supposed to use it) I guess the idea is to dissuade people from using hacks to enable unstable features -- this will break things which depend on the library. If a library compiles on stable, it should never break due to a compiler upgrade. (Tooling doesn't have this problem, it doesn't come into play when it's used on a dependency)
- pcwalton 10y ago
  The point is that your serious enterprise customers who can't change their toolchain also can't use AFL in GCC, so blaming Rust for this makes no sense. If anyone's to blame, it's AFL for needing custom compiler instrumentation. (Though I think that's a pretty weak criticism anyway.)
  - Manishearth 10y ago
    (Technically they can use AFL in gcc, just the less powerful version --which rust stable can too, if frewscxv adds it :). I'm not sure if a more powerful version for gcc exists, like it does for clang and rust)
    - aseipp 10y ago
      It does exist - I implemented it several months ago and demoed it for a local meetup for fun: https://github.com/thoughtpolice/afl/commit/e54c0237e934d7340d477a837eb891c4fe638b26 https://github.com/thoughtpolice/afl/commit/e54c0237e934d734... There was seemingly no interest at all in upstreaming this when I asked the afl-dev mailing list. My hope was that along with afl-clang-fast it could, in time, completely subsume the hacky `afl-gcc` and `afl-clang` scripts, making afl much faster, more robust and more portable out of the box (I initially tested on POWER8 machines). This component is under GPLv3, so it might possibly be due to licensing concerns. My other changes were accepted upstream (posted at a similar time), so that's just a speculative guess. People are seemingly interested in this and I've seen this question pop up a few times since authoring the code originally. Perhaps it is worth maintaining a fork or patchset for wider availability... The above code works, but is less efficient than `afl-clang-fast` and strictly proof of concept. Neither of those are insurmountable. In fact because this code works on GIMPLE very directly, I see no reason why it couldn't work for things like gccgo or gcj, or even GNU Ada or FORTRAN, I suppose, with some tweaks. Interestingly, a team at Oracle seems to have (at a similar, or later time) reinvented this same thing when they attempted to fuzz the Linux kernel with afl. But that source code doesn't exist publicly, it seems. Mine may not have even been suitable for them, even if they knew of it beforehand.
      - 10y ago

pjmlp 10y ago

Every time someone posts a cool Rust library, most of the time it makes use of nightly. How come can I advocate Rust to serious enterprise customers, if I have to justify using nightlies to make use of such tooling? Apparently downvoting every time someone mentions the issue with nightly being required is fair.

Eerie 10y ago
You can write your own code in stable Rust while using tooling that works on nightly. Rustup.rs makes it very easy to switch between stable and nightly.
- pjmlp 10y ago
  Assuming you are allowed control over the development environment, which isn't possible in many companies.
  - kouteiheika 10y ago
    Fortunately for Rust that's not an issue since you don't need any special privileges to install it; hell, it doesn't even have to be installed. As long as you point your $PATH to Rust's bin directory you can use it, as far as I know.
  - nemaar 10y ago
    If you work for a company that does not let you choose your compiler then I guess they probably will be stuck with a language more mainstream anyway. I doubt that the nightly compiler will be the dealbreaker.
    - pjmlp 10y ago
      On this companies using less mainstream languages like Swift, Go, F#, Haskell, OCaml isn't an issue because the communities don't depend on having nightlies installed.
Manishearth 10y ago
> Every time someone posts a cool Rust library, most of the time it makes use of nightly. Examples? Examples that aren't tools, that is. The main example I can think of is serde, and that works on stable (just works better on nightly). What's wrong with nightly for using tooling? You don't have to keep updating, you can pin to a nightly from a particular date. You can use rustup.rs to switch to stable locally if you need to. I said it's unfair, because gcc has worse issues here, and everyone probably agrees that gcc is "enterprise ready".
- pjmlp 10y ago
  Many companies let their IT control what toolchains one is allowed to use. Usually it is set in stone and only updated every few IT upgrade cycles. What the devs get on their machines is that and nothing more.
  - Manishearth 10y ago
    Good, install rustup.rs, with one date-pinned nightly, and stable. Freeze the rustup.rs install directory. Done?
    - yazaddaruvala 10y ago
      Lol, you're joking right? With respect, the Rust community is extremely in-exposed to the majority of actual enterprise environments, and that's ok. Honestly the best path forward is to just acknowledge it, say "we are working on it" and you'll get your point across better. Again with respect, because you all do really amazing work, fighting it honestly makes you and the whole community come across ignorant.
      - Manishearth 10y ago
        I'm not joking. Did you miss the part where I said the situation is worse for gcc? I do understand that this is a problem. I also do understand that it is not specific to Rust. Besides, convincing IT to allow rustup with an access-controlled toolchain directory shouldn't be a big deal in many cases. If they allowed one compiler, why not two? (Rustup can also be installed without sudo/admin, but I assume you are talking about situations where they want to restrict the executables running, not just globally installed executables). Yes, I know that in some cases they may not want two, but again, in those cases the GCC solution won't work either. Note that tools like nvm etc are also quite necessary in their respective spheres for serious development. I was once in a situation where I couldn't even install node at a modern version without nvm. For clippy, we are working on it, yes. For afl a simple fix exists (write the analog of -Xclang) but that fix will only work nicely if we ship llvm headers too which clang does (which we can, but it is a decision that can't be taken lightly). So no, we are not working on it. It is an interesting idea, and I will ping the relevant people (there are plans to ship "optional components" that you can obtain with rustup or download directly), but there are no concrete plans. The general evolution of Rust is towards everything being done through rustup. If you want to install a cross compile toolchain, clippy, get stdlib sources, or a different compiler version, use rustup. All the solutions to the nightly problem involve rustup. I.e. instead of installing nightly and using clippy, you just `rustup install clippy` or something and the relevant clippy binary (or compatible source?) will be downloaded, one which will work even if you are on stable. Basically, rustup will be the thing you install when you want to use rust. This is good, but as far as enterprise is concerned, you are still installing rustup, not rust. I'm not really sure what's wrong with this, but I'm sure some enterprise shops will have issues with this. For those which don't; the solution of having nightly installed via rustup in a frozen directory is not that much different, just unweildy. I have worked in places where the computer is locked down for many teams. But not in a place where it would be locked down in a way that rustc would be okay but rustup would not. I'd love to hear more about such cases and discuss how it can be addressed, but I'd prefer email (username@gmail or @mozilla.com). Thanks :)
frewsxcv 10y ago
In this particular instance, there's no reason to be shipping afl.rs in production code. It's just a tool that's meant for local development, testing environments, or maybe even part of a CI workflow.
wyldfire 10y ago
I think this is a legit complaint. I think I understand why the rust team wants folks to use nightlies for unstable features. But if you had to opt-in with special cargo/compiler flags then it would probably be sufficient.
- Manishearth 10y ago
  (Such a flag exists as an environment var, but you're not supposed to use it) I guess the idea is to dissuade people from using hacks to enable unstable features -- this will break things which depend on the library. If a library compiles on stable, it should never break due to a compiler upgrade. (Tooling doesn't have this problem, it doesn't come into play when it's used on a dependency)
pcwalton 10y ago
The point is that your serious enterprise customers who can't change their toolchain also can't use AFL in GCC, so blaming Rust for this makes no sense. If anyone's to blame, it's AFL for needing custom compiler instrumentation. (Though I think that's a pretty weak criticism anyway.)
- Manishearth 10y ago
  (Technically they can use AFL in gcc, just the less powerful version --which rust stable can too, if frewscxv adds it :). I'm not sure if a more powerful version for gcc exists, like it does for clang and rust)
  - aseipp 10y ago
    It does exist - I implemented it several months ago and demoed it for a local meetup for fun: https://github.com/thoughtpolice/afl/commit/e54c0237e934d7340d477a837eb891c4fe638b26 https://github.com/thoughtpolice/afl/commit/e54c0237e934d734... There was seemingly no interest at all in upstreaming this when I asked the afl-dev mailing list. My hope was that along with afl-clang-fast it could, in time, completely subsume the hacky `afl-gcc` and `afl-clang` scripts, making afl much faster, more robust and more portable out of the box (I initially tested on POWER8 machines). This component is under GPLv3, so it might possibly be due to licensing concerns. My other changes were accepted upstream (posted at a similar time), so that's just a speculative guess. People are seemingly interested in this and I've seen this question pop up a few times since authoring the code originally. Perhaps it is worth maintaining a fork or patchset for wider availability... The above code works, but is less efficient than `afl-clang-fast` and strictly proof of concept. Neither of those are insurmountable. In fact because this code works on GIMPLE very directly, I see no reason why it couldn't work for things like gccgo or gcj, or even GNU Ada or FORTRAN, I suppose, with some tweaks. Interestingly, a team at Oracle seems to have (at a similar, or later time) reinvented this same thing when they attempted to fuzz the Linux kernel with afl. But that source code doesn't exist publicly, it seems. Mine may not have even been suitable for them, even if they knew of it beforehand.
    - 10y ago