The Definition Of Maintained and Deprecated
pinkforest opened this issue · comments
EDIT: After @tarcieri comment I added "Deprecated"
I've been thinking of formal definitions
- Maintained (currently exists as Unmaintained) and
- Deprecated (currently does not exist)
As well as the implications and potential future implications of those two
Most of the open items in RustSec are maintenance related and I think they provide distraction.
Proposal
I propose to add distinction between "Deprecated" and "Unmaintained" by introducing "Deprecated" -
I think we should also run a parallel db for "Deprecated" crates where as for the unmaintained with "probably insecure" status could be relayed to Dependabot via GHSA where Deprecated fits the purpose of nudging users gently to consider alternatives.
I think that defining between these two with more clarity would give us benefit of being able to streamline the advisories around what crates not to use with appropriate levels of nudging -
Like for example sodiumoxide would be much better in a Deprecated database:
rustsec/advisory-db#1090
I believe the maintainer promised to merge security related patches but actively maintained is still "kind of bad" but not bad enough that it justifies necessarily an advisory entry -
If we keep "Maintained" strictly with "until proven / probably insecure" security focus - cargo audit would still continue to read the advisory-db where as "Deprecated" could be something else that could be early warning to switch before audit / Dependabot screams at you that it's insecure.
Community crates.io reflector #42 could also deter Deprecator use automatically -
Deprecated status could give maintainers incentitive to announce the crates they are not actively maintained or on other words graceful exit and signal potential to get someone to take over the maintenance.
Also we could perhaps have a definition to flag "Inactive" that by itself has no value but could flag further manual investigation with appropriate scoring from below factors
Say for example "Inactive" definition could involve -
- No commits in repository for a year
- No automatic dependency advisory workflow
- Maintainers no commits for a year
- Pending Issues with no Closed issues for x months
- ... ?
Refs
The process is currently an informal one, where someone nominates a crate as "unmaintained", and then one or more members of the WG attempt to reach out to the owner of the crate.
If the owner agrees the crate is unmaintained, or we don't receive a response for a prolonged period of time (months), we will merge an unmaintained crate advisory.
An important thing here is we're trying to keep the false positive rate as close to zero as possible, as these false positives are also a sort of "insult rate" to maintainers. We also don't want to be the straw that breaks the camel's back in terms of maintainer burnout (and there have been incidents like that in the past involving our WG, so we'd really like to tread carefully). Thus far we have always deferred to the maintainers regarding maintenance status, unless they're completely incommunicado.
Some sort of automation for determining the health of particular crates might be helpful in terms of determining what crates to mark as unmaintained, particularly one that emphasizes crates with large numbers of downloads or downstream dependencies. In general it'd be nice to have some sort of platform for doing analysis of the entire crates.io ecosystem.
However it's also important to note that lack of recent commit activity is not a proxy for a crate being unmaintained. Some crates do reach a state of being effectively "finished", where there is not a need for ongoing commit activity.
I edited to propose Deprecated status which would be more of a gentle nudge to switch off from the crate in near future.
We have added a policy describing what is an unmaintained crate:
https://github.com/rustsec/advisory-db/blob/main/HOWTO_UNMAINTAINED.md