Ignore `unmatched-organization` via configuration

[tgross35]

Is your feature request related to a problem? Please describe.

Some dependencies get flagged with unmatched-organization, and there doesn't seem to be a way to silence this warning with deny.toml

Describe the solution you'd like

Add a way to suppress this within deny.toml (or document it under https://embarkstudios.github.io/cargo-deny/checks/sources/diags.html if it already exists)

[Jake-Shadle]

I assume this is because you are sharing a config between multiple crates/repos/workspaces and don't want to get warnings from the ones which don't have those sources?

[tgross35]

In a way, mostly just looking to make the policy clear before any usecases actually come up. And so there isn't a need to update the deny.toml when dependencies are added/removed.

[Jake-Shadle]

Is there a reason you can't use -A unmatched-organization then?

[tgross35]

That works of course, it would just be nice if running cargo deny out of the box knew the proper lint level from the configuration file.

I suppose that isn't limited to just unmatched-organization, that is just the first warning I have come across that can't be otherwise configured.

[Jake-Shadle]

Lints regarding unused configurations options don't have ignore mechanisms within the configuration file itself, the whole point of them is to show users what options they have but aren't actually being used so they can have a smaller and cleaner config with only the things that matter, adding additional configuration to the same file to ignore other configuration in the same file is kind of self-defeating. It probably makes sense to add a single option to just ignore all config related lints like that instead if you don't care.

[LucasFA]

Not exactly the case posted here, but the default deny.toml file contains in the [sources.allow-org] lines like github = [""], resulting in unmatched-organization warnings out of the box when running cargo deny check sources.

Those fields are documented inline to require 1 or more orgs, but deleting the empty org works already by itself.

[Jake-Shadle]

The template it meant to show what configuration options are available, it's not meant to be committed as is.

[LucasFA]

For reference, cargo did exactly that, followed by some modifications for the licenses. And they did just deal with the warning by deleting the apostrophes, see rust-lang/cargo@7b747de959ae04b10793334876646c7186208fcc followed by rust-lang/cargo@aada2f34e094ada4e28c703acaf65cf70f6e2208

Evidently the template must be modified for, at least, the licenses, but I don't see the upside to keeping the apostrophes and requiring users to modify something only to satisfy cargo-deny.