First of all I would like to say thanks to everyone who contributed to this project and its original author! This project helped a lot with furthering adoption in restricted environments.

Potential security issues with downloading arbitrary crates from crates.io is a concern for most companies trying to adopt Rust. If anything history teaches us, it is easy to push malicious software into open registries and to receive malicious dependencies without notice. NPM registry is famous for these kinds of problems.

I'm thinking to implement whitelisting for crates, so that only a subset of crates.io could be downloaded for offline mirroring for the sake of security.

How I see this working

[crates.whitelist]
some-crate = { version = "1.2.3" } # download only 1.2.3 version
some-crate = { version = "^2.0.0" } # download everything up to 2.0.0 (inclusive)
some-crate = { version = "1.2.3", deps-download = false } # prevent dependency downloading

[crates.blacklist]
#  Possibility in the future

There should be a whitelisting file (probably crates.toml) which lists all crate names and their version ranges that should be downloaded.
All listed crates dependencies should be recursively downloaded by default
It should be possible to prevent downloading dependencies with an option

Since cargo resolves dependencies in a special way (i.e. downloading several versions of a single crate) the only option at the moment is to download everything up to the latest version specified in deps requirements of crates.io-index for the dependency. Example of crates.io-index entry:

{
"name": "serde",
"vers": "1.0.160",
"deps": [
{
  "name": "serde_derive",
  "req": "=1.0.160",
  "features": [],
  "optional": true,
  "default_features": true,
  "target": null,
  "kind": "normal"
},
{
  "name": "serde_derive",
  "req": "^1.0",
  "features": [],
  "optional": false,
  "default_features": true,
  "target": null,
  "kind": "dev"
}
],
"cksum": "bb2f3770c8bce3bcda7e149193a069a0f4365bda1fa5cd88e03bca26afc1216c",
"features": {
"alloc": [],
"default": [
  "std"
],
"derive": [
  "serde_derive"
],
"rc": [],
"std": [],
"unstable": []
},
"yanked": false
}

Downsides

The downside of this approach is that:

It can be tedious to list all the crates manually and update their version ranges every time. https://github.com/panamax-rs/panamax/issues/106
We can still hit issue with security by blindly downloading all dependency up to a last specified in deps index

Any thoughts on the matter are welcome!

panamax-rs / panamax

Crate whitelisting #109

How I see this working

Downsides