When publishing crates on crates.io, adopt certain blocking strategies for some testing/inappropriate publishing behaviors.
When a user runs the publish command of crates.io, the user sometimes publishes crates that do not contain real content. (Unused crates are released for test or experience purposes. For example, excessively long crate names or random character strings that are obtained using the hash method are released.)
In addition, the crate name or content contains insulting words, which may be a malicious attack. We may need to make judgments and alerts when publishing similar crates.
Too many meaningless crates published do not provide any help to the community and occupy service resources. The inclusion of insulting words may lead to unhealthy tendencies. This does not contribute to the healthy development of community technology and ecology.
We need to warn and even deny these unadvocated behaviors.
We should include judgments about sensitive words in the crate name and readme file in the publisher.
- Limit super-long crate names, which discourages adding dependencies in projects, reject publishing crate names that exceed 20 characters (20 characters) I thought of temporarily. The exact number of characters should be re-determined.
- Reject the release of irregular and meaningless crate names generated by using methods such as hash and base64.
- Search for insulting and unfriendly words, remind them when they are published, confirm whether to publish them, and provide a way to modify them later.
- Uploaded non-compliant crates are not deleted. However, reminders are provided for newly uploaded crates, explanation channels are provided, and the right to delete or change them is reserved.
For example, when a crate named [aA1ae777f650d92b903634047b1adaf0a26ece4125e7af5b75ef0d8709] or [aa2d74507d184541926d670b753d6843c0a5ea74dede83ab2d43260fa1] is released, neither the length requirement nor meaningless crate name is met. In this case, a notification or denial of service is required.
- The system checks whether the length of the crate name meets the release criteria. If the length does not meet the release criteria, the system prompts the user to return the modification. (For example, "The crate name you publish contains more than 20 characters. Please modify it before publishing.") Republished in.
- Retrieve sensitive information from the publication and set up reminders. For example, the system provides the notification service when publishing words such as bitch and fuck . (For example, "The crate you are about to post contains unfriendly words").
- Judges the crate names generated by using methods such as hash and base64 and refuses to provide publishing services. (How can I accurately determine the name of this type of crate?)
The time to release crate may be extended due to the addition of pre-release testing.
The current design is a check on crates.io. Perhaps you can also check the results when cargo is released. I think that since the final crate is published in crates, it is appropriate that this check is finally checked in crates.io.
There is no time to gain insights into other communities, to be added.
If a temporary test is required, check whether the measure that the crate can be automatically destroyed within 30 minutes is required. When releasing the crate, add a parameter to determine the existence time of the crate, for example, cargo publish --time 30min.
It's not entirely clear to me whether the behavior of including bitch fuck **, **, etc. is not allowed by the community.
I didn't think of it for now.