[RFC] Change our policy from 90 days to 270 days for unmaintained #2032
Conversation
But, in the event a vulnerability is reported, we'll consider a crate unmaintainted after a shorter 60 days
|
This is my proposal to reduce the volume of contentious unmaintained debates, and ideally also reduce burden/guilt/burnout concerns for maintainers. |
|
Upon further reflection, 270 days seems kind of arbitrary. 90 days has a lot of precedent, e.g. responsible disclosure windows. Perhaps we should go to 1 year (365 days)? |
|
I definitely don't remember what I was thinking when I picked 270 -- 365 would be fine with me. |
|
The 90 days sometimes really hurts me as I need to figure out how to handle these cases, but ... personally I like 90 days. That is three months of a maintainer being unresponsive. And that is after there is a problem with the maintenance that triggers someone to explicitly ask the maintainer if they are AWOL. Sort of relevant, https://github.com/trailofbits/cargo-unmaintained can be used to find unmaintained dependencies before they hit this CVE threshold. There are a few issues that I have raised that mean it isn't quite ready for being used in CI. |
| by the author over a period of 270 days (or 60 days of | ||
| unresponsiveness after being notified of a vulnerability) is the | ||
| minimum before a crate will be considered unmaintained. |
There was a problem hiding this comment.
I could like the 270/one year for unresponsiveness if
a) delay responding to a vuln is shorter. & clearer. Being "notified" of a vuln is not something that there is usually public evidence for. Note that before publishing, there is already a long window of time that the author is usually notified, and has time to respond privately. Sometimes the notification is privately disputed, and even the person notifying realises the vuln is not real. IMO it is simpler for this to be about "publication" rather than "notification". publication is when it becomes a problem for users. IMO 30 days is more reasonable for a published CVE.
b) there is a broader scenario that short-circuits the longer window. IMO we keep the 90 days, but expand it to approximately "PR that is widely desired by users" - I havent thought about how to describe this in a "policy" type wording.
There was a problem hiding this comment.
The reason I mention "PR" in the second bit is that raising an "issue" doesnt indicate the solution is important to users. A PR means there are users who put in the effort to solve the problem, especially if there are other users that have approved it. A non-vuln example is a syn-1 to syn-2 upgrade PR. That isnt a vuln, but users care about not having a syn-1 dep in their tree. If a maintainer is ignoring a syn-2 upgrade PR for three months, it is a pretty good indicator that there is a serious maintenance problem.
I second this opinion. IMO, 90 days seems like a reasonable threshold. |
But, in the event a vulnerability is reported, we'll consider a crate unmaintainted after a shorter 60 days