search

rust-secure-code / wg

Coordination repository for the Secure Code Working Group
151 stars 10 forks source link

The Definition Of Maintained and Deprecated #44

Open pinkforest opened 2 years ago

pinkforest commented 2 years ago

EDIT: After @tarcieri comment I added "Deprecated"

I've been thinking of formal definitions

1) Maintained (currently exists as Unmaintained) and 2) 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: https://github.com/rustsec/advisory-db/issues/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 -

Refs

tarcieri commented 2 years ago

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.

pinkforest commented 2 years ago

I edited to propose Deprecated status which would be more of a gentle nudge to switch off from the crate in near future.

Shnatsel commented 1 year ago

We have added a policy describing what is an unmaintained crate:

https://github.com/rustsec/advisory-db/blob/main/HOWTO_UNMAINTAINED.md

kpcyrd commented 7 months ago

Considering https://github.com/rustsec/advisory-db/pull/1922 and https://github.com/rustsec/advisory-db/issues/1925, I'm wondering if the definition of "unmaintained" should be clarified (or the category renamed even), at the moment it seems to be used as:

There is nobody around to do customer support for this crate

However, the opensource community (especially its volunteer community) is also based around:

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND

Unless there's some kind of support contract in place, an opensource dev doesn't owe a response if they don't consider something relevant enough.

I think inactivity alone shouldn't warrant an advisory, instead an actual defect in the code should be necessary. Even "has dependencies that can only be satisfied by vulnerable crates" wouldn't need an advisory, since these vulnerable crates already have advisories on their own. I think this category should instead mean:

Upstream explicitly doesn't want people to use this crate anymore and instead switch to alternatives

Which is still a valid category to have. Maybe the word "deprecated" could be a better fit.

Related issues:

CommanderStorm commented 7 months ago

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.

FYI (to prevent duplicate effort): I think solving this with https://github.com/szabgab/rust-digger/issues/69 might be a good/transparent/"sustainable" approach.