Proposal to add "features" to standard library

[bascule]

Some previous discussion of ideas along these lines:

[pre-pre-rfc?] Solving Crate Trust

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

(apologies if this has been discussed before, I couldn’t find anything) I touched on this problem in [pre-pre-rfc?] Solving Crate Trust, 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

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

The problem I assume that most readers here are aware of the recent flatmap-stream attack on Node. 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

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

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…

Cargo permissions to detect tampered dependecies

What is the problem? Crates.io, as many other package repositories have the challenge to keep all the available packages in a reliable and secure way. Developers and users of these repositories put a lot of confidence in repository maintainers. To keep a healthy repository of packages in crates.io we need to enforce as many as possible approaches to detect any kind of vulnerability. With the increased use of dependencies between packages, the risk of vulnerability propagation increases. A smal…

About supply-chain attacks

(Copying some stuff from the optional namespaces thread) There's been some recent discussion about a Medium post by a security researcher about the supply-chain attacks he performed on NPM, PyPI and RubyGems. While the specific attack isn't applicable to Cargo, I think it is a good illustration of the problem with vulnerabilities based on supply-chain attacks, typosquatting in particular: they accumulate quietly for a while, because attacks aren't really feasible in small ecosystem; and when a…

My take on this overall idea, which is similar to yours LucianoBestia (I called mine "unsafe features"):

Crate capability lists

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 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…