advisory-db
advisory-db copied to clipboard
rustsec
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.
Personally, I'm a strong -1 on this. We should be documenting vulnerabilities, which are approximately an objective criteria with clear implications for users. Expanding our scope a) dilutes how much time we can spend on anything, b) increases alert fatigue for many users, c) will consume a large amount of our limited maintainer time because definitionally, we will not all agree on controversial changes.
Personally, I'm a strong -1 on this. We should be documenting vulnerabilities, which are approximately an objective criteria with clear implications for users. Expanding our scope a) dilutes how much time we can spend on anything, b) increases alert fatigue for many users, c) will consume a large amount of our limited maintainer time because definitionally, we will not all agree on controversial changes.
These are all good reasons for doing this elsewhere. I'll give others a little while to think about it and have opinions.
Do I have your encouragement to do this as an independent project? I hope we'd be able to cooperate. Practical cooperation would include referring advisory submitters back and forth, collaboration on tooling, possible references in documentation, and so on.
Our existing advisory policy aims to be objective and defer to maintainers when in doubt.
I don't think it's our place to be making judgment calls about what decisions by maintainers are controversial. The community is clearly doing that on its own, especially in the case of #1738, which it's still not clear to me if it warrants an advisory from @RustSec or not.
There are many possible controversial things a crate could be doing. I fear a catch-all category for them would be too noisy, and having categories that have 1-2 advisories each is not particularly valuable.
https://github.com/EmbarkStudios/cargo-deny seems to be a good tool for enforcing potentially controversial or subjective policy in your projects.
