Dependency Resolution Hooks

[mitsuhiko]

I am interested in adding a hook point into cargo that would permit me to customize the process by which cargo picks packages from a registry. A simple way could be to just register an executable that uses some stdin/stdout based RPC mechanism. In the ideal world one could register hooks to be used via the global cargo config and require some hooks to be enabled in the Cargo.toml. Some usecases are blacklisting licenses, only use audited versions of packages, backlisting versions of packages that show up in rustsec's advisory db etc.

I'm not entirely sure yet where the best hook point would be but in the ideal situation such a hook would be invoked with the parsed package spec as well as the resolved packages, and can return a new list of packages either filtered down by removing them or by still retaining the package but leaving a marker that marks it as ineligible with a note as of why:

{"name": "libc", "version": "0.2", "matches": [...]}

[{
    "name": "libc",
    "version": "0.2.0",
    "id": "libc 0.2.0",
    "status": {
        "can_use": false,
        "icon": "X",
        "note": "This package has not been audited"
    }
}]

(No thought went into the above JSON payload, so let's not think too much about this yet)

I was looking at hacking something together but I could not find a good way to hook into the current resolution algorithm yet which is why I'm effectively asking for guidance from experienced cargo developers to figure out where such a system would go if it were to be added.

The motivation for adding this has been my blog post about scaling dependencies: http://lucumr.pocoo.org/2019/7/29/dependency-scaling/

[est31]

@mitsuhiko I think the easiest place to add this would be this iterator chain. That's also the place where yanked crates are being ignored. A while ago I wrote a prototype patch to add an --ignore-yanked flag as well as a (even prototype-ier) patch to respect the MSRV of crates.

Hooks would be extremely useful, even if they were only available for library users of cargo.

[spotlesscoder]

This could be very helpful to implement something like enforcement of a minimum release age that a package needs before cargo add will allow installing it - looking at all the recent supply chain attacks in the node ecosystem. Though I have bigger trust in rusts crate system than in npm, these of course can never be avoided 100%, so additional countermeasures are a good idea

[epage]

This could be very helpful to implement something like enforcement of a minimum release age that a package needs before cargo add will allow installing it - looking at all the recent supply chain attacks in the node ecosystem. Though I have bigger trust in rusts crate system than in npm, these of course can never be avoided 100%, so additional countermeasures are a good idea

Built-in support for minim-release age is being discussed in #15973. That is blocked on #15491 which is making progress.

[mikerooni]

There's another important thing I'd like to see being added in this regard:
The ability to block dependencies containing buildscripts or proc-macros, unless they are manually added to an allowlist (see also #13681).

As far as I understand, any cargo command (and by extension IDEs/editors through cargo check) currently builds dependencies first. If that's correct, this feature would probably have to be an option that can be set per-project and/or globally, as opposed to a commandline flag.

While this likely won't protect against situations where a malicious crate abuses proc-macros from another (benign) crate, it would be a first line of defense against supply chain attacks involving code executed at build time.

[epage]

Currently, that information is unavailable when resolving dependencies. When we work with a registry, we work off of an Index Summary. #15834 would add the information for proc-macros.