-
Notifications
You must be signed in to change notification settings - Fork 338
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handling of controversial decisions by crate authors #1750
Comments
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. |
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.
The text was updated successfully, but these errors were encountered: