If you recently used Cargo, make sure your system didn’t get infected. Here is another article with a little more info: https://www.stepsecurity.io/blog/arrayref-rust-crate-supply-chain-attack
If you recently used Cargo, make sure your system didn’t get infected. Here is another article with a little more info: https://www.stepsecurity.io/blog/arrayref-rust-crate-supply-chain-attack
In Java world package managers and package registries work with prebuilt libraries because for JVM bytecode it’s sufficient. And if they have native dependencies then they include compiled .dll or .so files that are built on developer’s machine. This makes things simpler but has its own drawbacks (these dependencies work only on architectures and OSes developer thought of, there is no guarantee that the library will be compatible with user’s environment, etc).
In Rust world everything is built from source, including native dependencies. Thsi makes build process much more complicated and necessitates running code on user’s (developer consumes the library as dependency, not end user) machine to build everything that’s not Rust.
I just wanted to ask, how do they build C libraries in JAVA world? And if the answer is they don’t, they just ship binaries, then that’s infinitely worse. And you just confirmed that’s the case 😲😄.
In reality it very rarely happens that native binaries are needed for Java. I’m not even sure what libraries might use them nowadays - I would guess mostly commercial closed source.
I don’t think it’s “infinitely worse”, but it does mean you require builds for whatever platform you are on or you need to manually build it from source as a separate project.
JVM, ELF, Mach-O,… binaries are infinitely worse when the attack vector is “compromised dev machine”.
I’m not sure how anyone would even try to argue against that.
Yep, it’s all binaries.