# Cargo permissions to detect tampered dependecies **URL:** \ **Category:** cargo\ **Created:** [May 21, 2019, 9:14pm UTC](https://internals.rust-lang.org/t/cargo-permissions-to-detect-tampered-dependecies/10236 "2019-05-21T21:14:42Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![bascule](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/bascule/32/3057_2.png) [@bascule](https://internals.rust-lang.org/u/bascule)\ **Post date:** [May 21, 2019, 10:07pm UTC](https://internals.rust-lang.org/t/cargo-permissions-to-detect-tampered-dependecies/10236/4 "2019-05-21T22:07:57Z")
Some previous discussion of ideas along these lines: > [@\[pre-pre-rfc?\] Solving Crate Trust](https://internals.rust-lang.org/t/pre-pre-rfc-solving-crate-trust/6495): > > Over time I’ve seen a bunch of problems brought up about trusting dependencies. While they’re different concerns with different threat models, I like to think of them as being different flavors of an overarching problem I call “crate trust”. I’d like to start a discussion about this, and propose one solution. This is a pre-pre-rfc with more of a sketch of a solution instead of specifics, and if folks like this I can move on to a more fleshed out pre-rfc. Problems Here are some of the problems i… > [@Build script capabilities](https://internals.rust-lang.org/t/build-script-capabilities/8635): > > (apologies if this has been discussed before, I couldn’t find anything) I touched on this problem in [[pre-pre-rfc?] Solving Crate Trust](https://internals.rust-lang.org/t/pre-pre-rfc-solving-crate-trust/6495), but it’s something worth splitting out. Currently, build scripts and compiler plugins (to a lesser degree) have unfettered power. They may end up doing whatever they want, and it’s hard to reason about them in the context of other build systems. There are a couple of things this impacts: Caching/artifact sharing: It’s hard to cache the results of crates com… > [@Crate capability lists](https://internals.rust-lang.org/t/crate-capability-lists/8933): > > In recent years it became popular in programming language communities to share large amount of code using various package managers. Rust is no exception, it is very easy to share your own code and use code written by others by using Cargo. At first sight, this seems to be a good thing. As time passes, more and more package will be available, eventually providing everything that someone may need in an every day software project. However, as shown by the community of Node.js, this solution is hard… > [@An idea to mitigate attacks through malicious crates](https://internals.rust-lang.org/t/an-idea-to-mitigate-attacks-through-malicious-crates/9006): > > The problem I assume that most readers here are aware of the recent [flatmap-stream attack on Node](https://www.theregister.co.uk/2018/11/26/npm_repo_bitcoin_stealer/). If you’re not, here’s the short version: the developer who managed a much-used library turned out to be malicious, and injected malicious code, which flew under the radar and was installed as dependency in gazillions of applications. The Rust ecosystem is vulnerable to the exact same kind of attack: one could imagine a malicious developer taking over, say, Itertools or some other popular crate th… > [@\[Pre-RFC\] Cargo Safety Rails](https://internals.rust-lang.org/t/pre-rfc-cargo-safety-rails/5535): > > Feature Name: cargo\_safetyrails Start Date: 2017-07-13 RFC PR: (leave this empty) Rust Issue: (leave this empty) Summary This RFC proposes Cargo Safety Rails, allowing crates to ensure that dependent crates don’t use unsafe language features. By declaring a dependency “untrusted”, the user tells cargo to compile it with the -F unsafe\_code option, preventing the dependency from using the unsafe keyword. Motivation Type safety allows the programmer to have strong guarantees about what incorpor… > [@Safe Library Imports](https://internals.rust-lang.org/t/safe-library-imports/9320): > > I want to be able to import libraries and know that they cannot access files or the network or use unsafe code. In particular, I want this for codecs, so that I can use them without having to audit the code. If I import a png library, I want to know it can only access the data I give it, do some computation and give data back to me. I can take care of network and file access for it. It could be a new keyword or keyword-alike: safe mod rustpng Ideally, there’d be a known-safe subset of the sta… I'm definitely a fan of this sort of idea. You can find my take on it here: > [@Crate capability lists](https://internals.rust-lang.org/t/crate-capability-lists/8933/2): > > I’ve been thinking along similar lines, but specifically around the problem of restricting usage of unsafe. I posted some initial thoughts here: [https://groups.google.com/d/msg/cap-talk/t9al5hjN19U/XzHfR1peBAAJ](https://groups.google.com/d/msg/cap-talk/t9al5hjN19U/XzHfR1peBAAJ) I’ve thought about posting a “Pre-Pre-RFC” about this, but I guess I can start by spitballing here. Unsafe Features Synopsis: Extend the existing idea of cargo features with a special notion of “unsafe features” which can be used to whitelist usage of unsafe in dependencies (and their… Also if you're interested in this sort of stuff, please check out the Rust Secure Code WG: > **[GitHub - rust-secure-code/wg: Coordination repository for the Secure Code...](https://github.com/rust-secure-code/wg)** > > Coordination repository for the Secure Code Working Group - GitHub - rust-secure-code/wg: Coordination repository for the Secure Code Working Group --- _[View the full topic](https://internals.rust-lang.org/t/cargo-permissions-to-detect-tampered-dependecies/10236)._