Handling of controversial decisions by crate authors

The recent serde drama is not the first time RustSec has been asked to issue an advisory regarding an intentional decision by a non-malicious crate author.

Another example is #1251 re cargo-husky (where I perceived pushback and didn't feel I wanted to press the issue, hence my non-response to the review comments). There have probably been others.

IMO the Rust community needs a database where surprising behaviour which is nevertheless intentional on the part of a crate author can be documented. This should be possible even for novel kinds of surprising crate behaviour - the criterion should be surprisingness to downstreams. So we mustn't be limited to a closed set of kinds of surprise (as some of the discussion in #1738 is debating). There should be processes that afford crate maintainers an opportunity to correct factual errors. But, reports should be accepted without pushback as seen in #1738 and #1251.

The handling of such political/process questions is a rather different kind of problem to RustSec's usual security response work. So it might well make sense to have some institutional separation. That could be a separate policy document, or a separate team, or by making this a separate project?

Is this a goal that RustSec want to address? If so then RustSec needs a documented process for handling "controversial" advisories. I would be happy to try to draft a proposal.

However, if RustSec don't want to take on these politically difficult questions, I am also happy to do this as an external project. If so I will probably want to reuse some of RustSec's tooling; so I might end up sending patches to allow cargo-audit to search more than one advisory source.

Please let me know what you think.

Read the discussion in issues #1738 and #1251, then determine whether RustSec wants to handle controversial intentional behavior and whether this belongs in a separate project or policy. Done would be an agreed documented process, or a clear decision to pursue an external project and identify any cargo-audit multi-source work needed.