Skip to content

Value of adding a --cooldown option to delay adoption of crate versions #963

@beavuck-dev

Description

@beavuck-dev

Supply-chain attacks can exploit Cargo's behavior of resolving a project's Cargo.toml restrictions to the newest compatible versions in Cargo.lock.

Other package managers have similar behavior -- for instance, notoriously, the community has suffered from supply-chain attacks through npm, with Trivy and Axios getting gravely compromised in March of this year.

In May, npm-check-updates added a --cooldown option to help prevent most of the impact of such attacks. Other package managers did or are doing the same.

Indeed, compromised package versions tend to be noticed in a matter of hours or days, the alarm is raised, the compromised versions get pulled. A 10-day cooldown would have protected anyone from both the Axios attack and the Trivy attack. Detection speed being roughly proportional to package popularity, adding a cooldown mechanism is simple and effective for supply chain attack mitigation.

Image

(from https://www.npmjs.com/package/npm-check-updates)

I'm writing this issue to ask you to assess the value (and effort) of adding a --cooldown option of your own to cargo-edit, to delay adoption of crate versions and help make software a bit safer.

I'm aware that there's an RFC currently happening about this topic in the rust-lang repo, so maybe Cargo itself is poised to implement a cooldown feature and cargo-edit doesn't need to. Is that correct?

Thank you for all the free cool stuff

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions