Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crate whitelisting #109

Closed
SoulSharer opened this issue May 1, 2023 · 1 comment
Closed

Crate whitelisting #109

SoulSharer opened this issue May 1, 2023 · 1 comment

Comments

@SoulSharer
Copy link
Contributor

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:

  1. It can be tedious to list all the crates manually and update their version ranges every time. Please add selective syncing #106
  2. 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!

@SoulSharer SoulSharer closed this as not planned Won't fix, can't repro, duplicate, stale May 22, 2023
@SoulSharer
Copy link
Contributor Author

It's been almost a month, closing, since I won't have time to devote to this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant