4 ms·

Worth noting that the JVM ecosystem doesn't have this issue because there is no notion of installing dependencies, and the package managers are just downloaders

Worth noting that the JVM ecosystem doesn't have this issue because there is no notion of installing dependencies, and the package managers are just downloaders with nothing else. No build.rs equivalent. To solve the problem of native/C dependencies, they just bundle pre-compiled libraries as data files. Rust could do the same thing.

ChrisSD 2mo ago
But then that shifts the issue. You've now got an opaque binary blob being injected into programs. What if it is malicious?
- mike_hearn 2mo ago
  It may or may not be a problem depending on whether it's actually used, which is still better than "gets you instantly the moment you compile the app". A lot of codepaths and even whole libraries aren't invoked just because a program depends on them. It doesn't really matter anyway, because nobody is reading anything in their dependencies before it gets downloaded. Malware can also be hiding in plain sight in source code, as this attack and many others shows.
pie_flavor 2mo ago
ABI stability is significantly different in a VM language to a native language, and reified generics necessarily require source compilation. Binary-only development for Rust would be exactly as 'sort of not really' as C++, for exactly the same reasons. (There is also no notion of 'installing' dependencies in Rust, and build-time code being malicious isn't much worse than runtime code being malicious.)
- mike_hearn 2mo ago
  But people say build.rs is used mostly to compile C dependencies, in which case the lack of ABI stability of Rust is neither here nor there.
  - pie_flavor 2mo ago
    It's used to do all sorts of things. Rust version probing, bindings generation, precompiling bundled data, etc. The only reason it isn't used to do more is because proc macros do it instead, with an essentially identical execution model and sandboxing situation (ie build scripts in isolation are a red herring).
looperhacks 2mo ago
[dead]

ChrisSD 2mo ago

But then that shifts the issue. You've now got an opaque binary blob being injected into programs. What if it is malicious?

mike_hearn 2mo ago
It may or may not be a problem depending on whether it's actually used, which is still better than "gets you instantly the moment you compile the app". A lot of codepaths and even whole libraries aren't invoked just because a program depends on them. It doesn't really matter anyway, because nobody is reading anything in their dependencies before it gets downloaded. Malware can also be hiding in plain sight in source code, as this attack and many others shows.

pie_flavor 2mo ago

ABI stability is significantly different in a VM language to a native language, and reified generics necessarily require source compilation. Binary-only development for Rust would be exactly as 'sort of not really' as C++, for exactly the same reasons. (There is also no notion of 'installing' dependencies in Rust, and build-time code being malicious isn't much worse than runtime code being malicious.)

mike_hearn 2mo ago
But people say build.rs is used mostly to compile C dependencies, in which case the lack of ABI stability of Rust is neither here nor there.
- pie_flavor 2mo ago
  It's used to do all sorts of things. Rust version probing, bindings generation, precompiling bundled data, etc. The only reason it isn't used to do more is because proc macros do it instead, with an essentially identical execution model and sandboxing situation (ie build scripts in isolation are a red herring).

looperhacks 2mo ago

[dead]