Crates.io: Avoid maliciously or inadvertently uploaded zero value crates

[vrdhn]

This issue addresses people stumbling on crates like https://docs.rs/crate/crypto/0.0.2/source/src/lib.rs

Why this is a problem:

• people will use this, thereby increasing the use count, and this becomes a loop.
• useful packages get hidden behind the noise ( first exact hit )
• becomes the classic 'broken window'

What can be done

• Automatic checks: valid author email ( with verification!), scanty description, library with no public symbols, valid repo ( if open-source license )
• Automatic checks: periodic 'click on this link to verify email' for authors.
• Flagging , and a core team takes call on removing or keeping
• Thumbs up/down for letting community score the crate. ( download count is not enough, malicioous use can cron them)

[ashleygwilliams]

i think this type of policy would warrant an RFC! are you interested in writing one?

[vrdhn]

The problem of name squatting is entirely different ( on which I do not have a opinion).

The problem I'm looking to get solved is

Make sure an bogus crate is marked as one.

There are multiple ways of doing this, some I noted in description, and others
which community will come up with.

Do you think this change in the crates.io functionality requires an RFC.
If yes, I'ld be very intrested in writing one.

[jtgeibel]

I'm not sure I see the distinction between name squatting and zero value crates as described here. The linked crate has no public dependent crates shown on crates.io even though it has been published for 2.5 years.

I agree that any policy changes affecting the publishing of crates should solicit feedback from the broader community and that the RFC process is probably the best place for that.

[sgrif]

Closing this, as there's nothing actionable we can do here without an RFC.