Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[RFC] Change our policy from 90 days to 270 days for unmaintained #2032

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

[RFC] Change our policy from 90 days to 270 days for unmaintained #2032

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 3 additions & 2 deletions HOWTO_UNMAINTAINED.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -57,8 +57,9 @@ unreachable, the following criteria must be met:
- Contact attempts with the author made with no response. Ideally these
attempts are made via a public GitHub issue, so that issue can be
cited in an unmaintained crate advisory if need be. Unresponsiveness
by the author over a period of 90 days is suggested before filing an
advisory.
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.
Comment on lines +60 to +62
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


### Process

Expand Down