Provide a way to filter out crates

[jyn514]

For rustc itself, supply-chain shows the following crates as dependencies:

270. rustc-ap-rustc_arena: alexcrichton
271. rustc-ap-rustc_ast: alexcrichton
272. rustc-ap-rustc_ast_passes: alexcrichton
273. rustc-ap-rustc_ast_pretty: alexcrichton
274. rustc-ap-rustc_attr: alexcrichton
275. rustc-ap-rustc_expand: alexcrichton
276. rustc-ap-rustc_feature: alexcrichton
277. rustc-ap-rustc_fs_util: alexcrichton
278. rustc-ap-rustc_graphviz: alexcrichton
279. rustc-ap-rustc_index: alexcrichton
280. rustc-ap-rustc_lexer: alexcrichton
281. rustc-ap-rustc_macros: alexcrichton
282. rustc-ap-rustc_parse: alexcrichton
283. rustc-ap-rustc_serialize: alexcrichton
284. rustc-ap-rustc_session: alexcrichton
285. rustc-ap-rustc_span: alexcrichton

But none of these are actually dependencies - these are the rustc crates themselves, just with a different name. So they should be ignored as if they were in-tree. cargo-supply-chain has no way of knowing these are the same crate, so it would be nice to have a way to tell it.

Possibly this should be a feature request for cargo metadata instead?

[Shnatsel]

We've added cargo supply-chain json command so you can get the structured data out of it and manipulate it in whatever way you see fit. Does that address your use case?

I suppose we could add some sort of configuration file, but I'm not thrilled about contents of the repo changing the way auditing/reporting on the code works.

[jyn514]

Well, it's about to be a moot point anyway with https://github.com/rust-lang/rust/pull/82208.

I don't think this is super necessary, supply-chain doesn't work very well on rust-lang/rust anyway because there are lots of out-of-tree dependencies that are still maintained by members of the org.

[Shnatsel]

Is there anything we can do to help with that? Those maintainers should be listed along with the crates, and there's also a publishers subcommand that groups the data by maintainers instead of crates.

[jyn514]

Hmm, if there were an-opt a way to

• Ignore crates in the same org for crates, and
• Ignore maintainers in the same org for publishers

that would be pretty useful I think.

[Shnatsel]

crates.io operates in terms of teams, not orgs, for controlling publishing rights, and org membership can be private to boot. So this would require authenticating the tool to your Github org to let it view the team membership information. If that's an acceptable trade-off, I'd be happy to take a feature request.