# \[pre-pre-rfc?\] Solving Crate Trust **URL:** \ **Category:** cargo\ **Created:** [January 8, 2018, 11:14am UTC](https://internals.rust-lang.org/t/pre-pre-rfc-solving-crate-trust/6495 "2018-01-08T11:14:00Z")\ **Posts on this page:** 14\ **Page:** 2
**Author:** ![H2CO3](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/h2co3/32/2849_2.png) [@H2CO3](https://internals.rust-lang.org/u/H2CO3)\ **Post date:** [January 10, 2018, 5:20pm UTC](https://internals.rust-lang.org/t/pre-pre-rfc-solving-crate-trust/6495/21 "2018-01-10T17:20:04Z")
Very nice pre-pre-RFC, although I don’t understand why opt-out/allow-by-default/blacklist for many capabilities instead of opt-in/deny-by-default/whitelist? Given that we are explicitly talking about a security/safety/trust problem here, shouldn’t we just be extra vigilant and as strict as possible? For example, I would very much like "allowed to use `unsafe`" to be denied by default. In my experience, many crates that use `unsafe` really don’t **need** the `unsafe`. Some programmers use it for “optimization” purposes; others are C programmers trying to avoid learning how to borrowck; and very few are actual, legitimate users who are trying to call into a C library or write a safe primitive to build on. Related: I am currently working on a project that will explicitly advertise itself as "transitively free of `unsafe`". For now, it means that I have gone through every dependency of my project one-by-one, recursively, and verified if/how they use `unsafe` in any of the functions/types I am using from them. I’ve also submitted pull requests that remove unnecessary `unsafe`s from several such depended-upon-by-me crates in the course. In the future, if I update any of these crates, I will need to go through it again. To mitigate this, I think many of us would appreciate some sort of tooling, e.g. `cargo safe`, that would allow one to query and track uses of `unsafe` in the transitive dependencies. ---
**Author:** ![Manishearth](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/manishearth/32/50_2.png) [@Manishearth](https://internals.rust-lang.org/u/Manishearth)\ **Post date:** [January 10, 2018, 5:40pm UTC](https://internals.rust-lang.org/t/pre-pre-rfc-solving-crate-trust/6495/22 "2018-01-10T17:40:45Z")
> [@H2CO3](#): > > Given that we are explicitly talking about a security/safety/trust problem here, shouldn’t we just be extra vigilant and as strict as possible? Because we don't know _which_ security problem the user is concerned about; it is up to them to pick. This RFC is providing a framework that lets users decide what issues they care about and then audit for those. Also, if this is built into cargo, capabilities being opt-out is a breaking change. > For example, I would very much like "allowed to use unsafe" to be denied by default. In my experience, many crates that use unsafe really don’t the need the unsafe. This does not match up with my experience. Plenty of crates need it, especially FFI. There are amateurish crates out there, sure, but that's a problem _anyway_, you should be picking good crates. > To mitigate this, I think many of us would appreciate some sort of tooling, e.g. cargo safe, that would allow one to query and track uses of unsafe in the transitive dependencies. This is ... basically what is being proposed here? A superset solution. ---
**Author:** ![vorner](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/vorner/32/3310_2.png) [@vorner](https://internals.rust-lang.org/u/vorner)\ **Post date:** [January 10, 2018, 6:21pm UTC](https://internals.rust-lang.org/t/pre-pre-rfc-solving-crate-trust/6495/23 "2018-01-10T18:21:25Z")
I see this might be useful (I’m not really trying to decide if this exact set of capabilities is best, I mean the general idea). I’m a bit worried about the initial scope ‒ would it make sense to start small first? Also, this is just the first step. This tells me which dependencies I might want to audit, but it doesn’t help me with the audit itself. I understand it is not the goal, but maybe it would be worth stating explicitly as non-goal (when I read the title, I kind of expected this to be addressed as well). I also think some kind of signatures/reviews/audits published to [crates.io](http://crates.io) (or elsewhere) could help with the other half ‒ at least for individual developers without the means to audit everything they have ‒ firefox has a large team and the resources. If I want to do my own little program, I want it to be safe, but I don’t have the means to check everything myself. But yes, that’s probably different part of the puzzle. ---
**Author:** ![bjorn3](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/bjorn3/32/2736_2.png) [@bjorn3](https://internals.rust-lang.org/u/bjorn3)\ **Post date:** [January 11, 2018, 6:13pm UTC](https://internals.rust-lang.org/t/pre-pre-rfc-solving-crate-trust/6495/24 "2018-01-11T18:13:36Z")
> [@canndrew](#): > > Users are able to endorse each other. I can tell [crates.io](http://crates.io) that I trust @bob by b, then anyone who trusts me by x and would otherwise trust @bob by y would now trust @bob by max(y, x \* b). (Or maybe some other formula. We’d need to do the math / game theory to work out what the correct probability would be) Maybe use google's pagerank ---
**Author:** ![kornel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kornel/32/2711_2.png) [@kornel](https://internals.rust-lang.org/u/kornel)\ **Post date:** [January 11, 2018, 8:00pm UTC](https://internals.rust-lang.org/t/pre-pre-rfc-solving-crate-trust/6495/25 "2018-01-11T20:00:11Z")
Another failure mode: > **[Firms buy popular Chrome extensions to inject malware, ads | ZDNet](http://www.zdnet.com/article/firms-buy-popular-chrome-extensions-to-inject-malware-ads/)** > > Are adware companies offering lucrative deals to acquire popular Chrome extensions -- and the trust of an extension's users? This could potentially happen with Cargo — author of a popular crate may decide to sell it or accept a lucrative deal to “monetize” it. This means that even age and popularity of a crate is not a guarantee the crate won’t become malware ☹ ---
**Author:** ![mark-i-m](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/mark-i-m/32/3167_2.png) [@mark-i-m](https://internals.rust-lang.org/u/mark-i-m)\ **Post date:** [January 11, 2018, 8:33pm UTC](https://internals.rust-lang.org/t/pre-pre-rfc-solving-crate-trust/6495/26 "2018-01-11T20:33:17Z")
Trust is not transitive. In the end, it will probably come down to auditing and community endorsement, I think… ---
**Author:** ![taralx](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/taralx/32/3026_2.png) [@taralx](https://internals.rust-lang.org/u/taralx)\ **Post date:** [January 12, 2018, 2:27am UTC](https://internals.rust-lang.org/t/pre-pre-rfc-solving-crate-trust/6495/27 "2018-01-12T02:27:05Z")
My biggest concern with this is that crates often seem to extend their functionality and thus acquire additional dependencies that _I do not want and will not use_. The ergonomics around splitting the functionality of a crate is not great right now. ---
**Author:** ![gavento](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/gavento/32/2315_2.png) [@gavento](https://internals.rust-lang.org/u/gavento)\ **Post date:** [January 16, 2018, 10:37pm UTC](https://internals.rust-lang.org/t/pre-pre-rfc-solving-crate-trust/6495/28 "2018-01-16T22:37:16Z")
> [@taralx](#): > > My biggest concern with this is that crates often seem to extend their functionality and thus acquire additional dependencies that I do not want and will not use. The ergonomics around splitting the functionality of a crate is not great right now. Would [cargo features](https://doc.rust-lang.org/cargo/reference/manifest.html#the-features-section) help with optional functionalities and their dependencies? It would be an additional aspect complicating the RFC, but it might be worth mentioning. ---
**Author:** ![HaronK](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/haronk/32/3117_2.png) [@HaronK](https://internals.rust-lang.org/u/HaronK)\ **Post date:** [January 16, 2018, 11:39pm UTC](https://internals.rust-lang.org/t/pre-pre-rfc-solving-crate-trust/6495/29 "2018-01-16T23:39:36Z")
About a year ago I have read a post about [reproducibility of the rustc releases](https://internals.rust-lang.org/t/verifying-rustc-releases-with-reproducible-builds/4502) (there is also an [issue](https://github.com/rust-lang/rust/issues/34902) for this). I think the same approach applied to the **[crates.io](http://crates.io)** libraries can make them more secure. At least anyone would be able to reproduce a build and compare it with one from the **[crates.io](http://crates.io)** (or it can be done automatically). I know we depend on LLVM but as it was discussed in the post I mentioned above everything can be solved. ---
**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:** [January 17, 2018, 12:19am UTC](https://internals.rust-lang.org/t/pre-pre-rfc-solving-crate-trust/6495/30 "2018-01-17T00:19:34Z")
> [@dhardy](#): > > This is an important point. When I type cargo publish, it’s the code in my local directory which gets used, not the code in some public repository. Maybe instead publish should take a commit on a pulbic GitHub repo, clone that repo into a GH team belonging to the Cargo team, make a signed tag, build from that, and then sign the build (all on a build server). There are a few challenges with this, namely that as far as I understand releasing a crate right now involves building it, which may involve procedural macros, and in that case it's tantamount to RCE. It'd be nice if such a build system wasn't a terrifying single point of compromise. I covered some ways to address this, specifically through the use of reproducible builds and scoped credentials, in my Rust Bay Area Meetup talk on Macaroons last year: [https://air.mozilla.org/rust-meetup-february-2017-02-09/](https://air.mozilla.org/rust-meetup-february-2017-02-09/) (start at 32:15) ---
**Author:** ![matejcik](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/matejcik/32/3775_2.png) [@matejcik](https://internals.rust-lang.org/u/matejcik)\ **Post date:** [March 12, 2018, 3:00pm UTC](https://internals.rust-lang.org/t/pre-pre-rfc-solving-crate-trust/6495/31 "2018-03-12T15:00:44Z")
hello, I’m looking into this as a possible topic for my masters thesis. I’d like to do something like an overview of the whole problem (“trust in third-party libraries and dependencies”), with applicability and implementation specifically for Rust and [crates.io](http://crates.io). I’m at the stage where I’m not even entirely sure what the end result would look like. At the moment, the following features look interesting: - a mechanism to tie a published package on [crates.io](http://crates.io) to a specific git(hub) commit (which can be signed, and this signature maybe used in place of, or in addition to, a separate crate signature?) - a mechanism to attach third-party signatures to this thing - for “trusted audits” that @kornel talked about - something about auditing subsequent commits, so that it’s easier to upgrade a package from a known good version - TUF-inspired mechanism(s) that would ensure integrity of the whole scheme, key revocation, etc. I’m mostly thinking about the trust model and the general “allowed to exist” capability; more granular capabilities could maybe piggyback on the same basic underlying scheme (audit related to unsafe code only? to code harm overall? build scripts?), but I specifically _don’t_ aim to solve granular enforcement, such as sandboxing. I’m still trying to connect all the dots and form a more complete picture of the problem. I’ve been reading about TUF (and [https://github.com/rust-lang/crates.io/issues/75](https://github.com/rust-lang/crates.io/issues/75)) and similar. Are there more resources and/or related discussions that you could point me towards? ---
**Author:** ![Manishearth](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/manishearth/32/50_2.png) [@Manishearth](https://internals.rust-lang.org/u/Manishearth)\ **Post date:** [March 12, 2018, 6:06pm UTC](https://internals.rust-lang.org/t/pre-pre-rfc-solving-crate-trust/6495/33 "2018-03-12T18:06:28Z")
> hello, I’m looking into this as a possible topic for my masters thesis This sounds great! Let me know how I can help! > [@matejcik](#): > > a mechanism to tie a published package on [crates.io](http://crates.io) to a specific git(hub) commit (which can be signed, and this signature maybe used in place of, or in addition to, a separate crate signature?) FWIW @withoutboats is working on stuff in this space already > but I specifically don’t aim to solve granular enforcement, such as sandboxing. I think that's fine -- I think having the ability to specify granular capabilities is important, but a different tool can _enforce_ the capabilities. So your tool may allow users to specify/allow/deny various sandboxing-related capabilities, and we can have the build system query it to actually sandbox things. > I’m mostly thinking about the trust model and the general “allowed to exist” capability; more granular capabilities could maybe piggyback on the same basic underlying scheme (audit related to unsafe code only? to code harm overall? build scripts?), I suspect it will be easier to do in the other direction -- solve the problem for the general notion of capabilities (In general I think trust is very multidimensional), and then "allowed to exist" and "allowed to unsafe" are specific variants of this. _Enforcing_ "allowed to unsafe" can be done later, but having some way of specifying simultaneously "I am okay with this crate but it is not allowed to use unsafe", which can later interface with a tool that forbids unsafe -- would be nice. > Are there more resources and/or related discussions that you could point me towards? I don't know where boats' [crates.io](http://crates.io) signature stuff is, but TUF and that are the only two things I can think of. ---
**Author:** ![notriddle](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/notriddle/32/14082_2.png) [@notriddle](https://internals.rust-lang.org/u/notriddle)\ **Post date:** [April 16, 2018, 7:41pm UTC](https://internals.rust-lang.org/t/pre-pre-rfc-solving-crate-trust/6495/34 "2018-04-16T19:41:18Z")
> [@Manishearth](#): > > > [@matejcik](#): > > > > a mechanism to tie a published package on [crates.io](http://crates.io) to a specific git(hub) commit (which can be signed, and this signature maybe used in place of, or in addition to, a separate crate signature?) > > FWIW @withoutboats is working on stuff in this space already This is probably the worst attack model Cargo has right now, since it means people trying to audit their crates can easily end up not actually auditing the code they're using (like that NPM-related article). Ideally, [crates.io](http://crates.io) would refuse to publish a crate if it links to GitHub but doesn't have the same code as the repo it links to. ---
**Author:** ![Manishearth](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/manishearth/32/50_2.png) [@Manishearth](https://internals.rust-lang.org/u/Manishearth)\ **Post date:** [March 25, 2019, 8:29am UTC](https://internals.rust-lang.org/t/pre-pre-rfc-solving-crate-trust/6495/35 "2019-03-25T08:29:28Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed. [Previous page](https://internals.rust-lang.org/t/pre-pre-rfc-solving-crate-trust/6495.md?page=1)