SAN FRANCISCO, CA - In the wake of a devastating supply chain attack in the npm registry that left millions of enterprise applications compromised and billions of user records exposed, developers across the JavaScript ecosystem expressed deep sorrow today, lamenting that such a crisis was completely unavoidable. “It’s a shame, but what can you do? This is just the price of building modern web apps,” said Senior Frontend Engineer Mark Vance, echoing the sentiments of a community that completely relies on a 40-level-deep nested tree of unvetted packages maintained by pseudonymous strangers to capitalize a single string. “There’s absolutely no way to foresee or prevent someone from taking over a long-abandoned utility package and injecting a crypto-miner into every production build in the world. It’s just an act of nature.”
  • josephc@lemmy.ml
    4·
    5 hours ago

    Unlike javascript, where at least it is an interpreted language people can audit, you would have to reverse engineer these binaries to figure out what they do.

    If you cargo install something you get source code (unless the library packages a binary, but that’s the same as if it were JS or Python or C). Rust dependencies don’t become binary until the final product.

    Auditing Rust binaries isn’t much worse than auditing minified and uglified JS. I’ve done both.

    EDIT:

    Rust

    Rust is doing pretty poorly right now.

    among the 999 most popular crates on crates.io, around 17% contained code that do not match their code repository.

    https://kerkour.com/rust-supply-chain-nightmare

    I just went through the article and I don’t think I agree with the assessment that “Rust is doing pretty poorly right now.” It feels disingenuous, given the content of the article you linked:

    826 crates match their upstream repositories at the revision they were built at. 74 crates have revisions that cannot be found in their repositories, whether due to later squash merges, rebases or revisions simply not being pushed. 73 crates do not have VCS info, either because they were built with old Cargo versions, built with --allow-dirty, or not built from a repo clone at all. 77 crates do not declare a repository in their Cargo manifest. 7 crates would match their upstream repository but for one or more symlinks being incorrectly handled. 3 crates declare repositories that do not exist. 3 crates have submodules that do not exist. 3 crates cannot be found within their repositories. 3 crates cannot be built due to cargo package errors. … Only 8 crate versions straight up don’t match their upstream repositories. None of these were malicious: seven were updates from vendored upstreams (such as wrapped C libraries) that weren’t represented in their repository at the point the crate version was published, and the last was the inadvertent inclusion of .github files that hadn’t yet been pushed to the GitHub repository.

    • HiddenLayer555@lemmy.mlEnglish
      2·
      6 hours ago

      I’d imagine Rust’s strict enforcement of a few specific patterns makes the assembly more predictable than C/++ where you can do literally anything?