• Technus@lemmy.zip
    link
    fedilink
    arrow-up
    15
    ·
    edit-2
    3 hours ago

    Interestingly, developers in ecosystems like Go, Rust, and those utilizing native Web APIs—where robust standard libraries drastically reduce reliance on third-party code and strict cryptographic verification is built into the core toolchain—reported zero instances of a college dropout’s weekend project wiping out global logistics infrastructure today.

    As someone who’s built a career in Rust, it is 100% susceptible to an attack like this. The community is just generally paranoid enough to avoid depending on super niche packages.

    Even so, Cargo still doesn’t have code signing and crates.io doesn’t have 2FA. They just barely rolled out email alerts for new crates being published with your API key.

    And there’s dozens of single-author crates that are depended upon by millions of lines of code, any one of which could easily be a vector in a supply chain attack. In fact there have been attempted supply chain attacks against crates.io, but to my knowledge they’ve all relied on typo-squatting.

    We’re definitely overdue for a major attack.

    • iocase@lemmy.zip
      link
      fedilink
      arrow-up
      1
      ·
      32 minutes ago

      I guess one benefit is rust development often doesn’t use bleeding edge version for everything, where you pull the entirety of crates.io through your machine when you open your IDE. From what I’ve seen most projects use == versions and lock files.

      I don’t know enough about rust though. Could an attacker change historical crate versions to a payload and then cargo pulls them because they changed? Or will cargo only pull an update if you change to a different version on your machine?

      • brucethemoose@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        23 seconds ago

        That sounds better and worse. An attack could persist past one specific version without anyone noticing for a bit.

      • Technus@lemmy.zip
        link
        fedilink
        arrow-up
        1
        ·
        15 minutes ago

        You can’t overwrite previously published versions.

        Application projects are recommended to check-in the Cargo.lock which pins dependency versions but you can always just run cargo update at any time which automatically upgrades all dependencies to the newest version allowed by the Cargo.toml.

        Some projects get around this by pinning the dependency in the Cargo.toml (using =) or by vendoring all their dependencies, which is a huge pain in the ass.