-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Add "crates.io Policy Update" RFC #3463
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.
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
Changes from 2 commits
5ea4917
2a9a604
a2ce165
fab5d16
2c99c00
136d071
9101524
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,233 @@ | ||
| - Start Date: 2023-07-24 | ||
| - RFC PR: [rust-lang/rfcs#3463](https://github.com/rust-lang/rfcs/pull/3463) | ||
|
|
||
| # Summary | ||
| [summary]: #summary | ||
|
|
||
| The Rust community has outgrown the current crates.io policies. This RFC proposes a new "Terms of Use" policy based on prior work by PyPI, npm and GitHub. | ||
|
|
||
| # Motivation | ||
| [motivation]: #motivation | ||
|
|
||
| > Why are we doing this? What use cases does it support? What is the expected outcome? | ||
|
|
||
| crates.io has a "[Package Policies](https://crates.io/policies)" page, which describes the current, organically grown policies. A lot of support requests or questionable uses of crates.io however need explicit decisions from the crates.io team, since many cases are currently not covered by these policies. Additionally, decisions made by the team may be seen as arbitrary without written guidelines. | ||
|
|
||
| The situation around name squatting has lately also reached unsustainable levels, and while [namespaces](https://github.com/rust-lang/rfcs/pull/3243) might help with some parts of the problem we would still need policies for name squatting namespaces then. | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| The main motivation for this RFC is to give the crates.io team a fixed set of rules to determine if a project is using crates.io in a reasonable way, or if the user should get a warning and the project potentially be removed. It is mostly codifying the existing practices of the team, except for being more strict regarding name squatting. | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| # Proposal | ||
| [guide-level-explanation]: #guide-level-explanation | ||
|
|
||
| The following is a proposed new "Terms of Use" policy for crates.io, replacing <https://crates.io/policies> and <https://crates.io/data-access>. | ||
|
|
||
| ------------------------------------------------------------------------------- | ||
|
|
||
| # Terms of Use | ||
|
|
||
| **Short version:** _crates.io is a critical resource for the Rust ecosystem, | ||
| which hosts a variety of packages from a diverse group of users. That resource | ||
| is only effective when our users are able to work together as part of a | ||
| community in good faith. While using crates.io, you must comply with our | ||
| Acceptable Use Policies, which include some restrictions on content and conduct | ||
| on crates.io related to user safety, intellectual property, privacy, | ||
| authenticity, and other limitations. In short, be excellent to each other!_ | ||
|
|
||
| We do not allow content or activity on crates.io that: | ||
|
|
||
| - violates the [Code of Conduct](https://www.rust-lang.org/policies/code-of-conduct) | ||
| of the Rust project | ||
| - is unlawful or promotes unlawful activities, incurring legal liability in the | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| countries the Rust Foundation officially operates in | ||
| - is libelous, defamatory, or fraudulent | ||
| - amounts to phishing or attempted phishing | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - infringes any proprietary right of any party, including patent, trademark, | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| trade secret, copyright, right of publicity, or other right | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - unlawfully shares unauthorized product licensing keys, software for | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| generating unauthorized product licensing keys, or software for bypassing | ||
| checks for product licensing keys, including extension of a free license | ||
| beyond its trial period | ||
| - contains malicious code, such as computer viruses, computer worms, rootkits, | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| back doors, or spyware, including content submitted for research purposes | ||
| (tools designed and documented explicitly to assist in security research are | ||
| acceptable, but exploits and malware that use the crates.io registry as a | ||
| deployment or delivery vector are not) | ||
| - uses obfuscation to hide or mask functionality | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - is discriminatory toward, harasses or abuses another individual or group | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - threatens or incites violence toward any individual or group, especially on | ||
| the basis of who they are | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - is using crates.io as a platform for propagating abuse on other platforms | ||
| - violates the privacy of any third party, such as by posting another person's | ||
| personal information without consent | ||
| - gratuitously depicts or glorifies violence, including violent images | ||
| - is sexually obscene or relates to sexual exploitation or abuse, including of | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| minors (see <https://docs.github.com/en/site-policy/acceptable-use-policies/github-sexually-obscene-content>) | ||
Turbo87 marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| - is false, inaccurate, or intentionally deceptive information and likely to | ||
| adversely affect the public interest (including health, safety, election | ||
| integrity, and civic participation) | ||
Turbo87 marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| - is off-topic, or interacts with platform features in a way that significantly | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| or repeatedly disrupts the experience of other users | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - exists only to reserve a name for a prolonged period of time (often called | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| "name squatting") without having any genuine functionality, purpose, or | ||
| significant development activity on the corresponding repository | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - is related to buying, selling, or otherwise trading of package names or any | ||
| other names on crates.io for money or other compensation | ||
| - impersonates any person or entity, including through false association with | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We had a situation where another developer forked an unpublished crate from our public GitHub, then published it on crates.io. In that specific case, we had used a generic crate name, so we were able to choose a similar new name. But what would happen if they had used the name of our project as a crate name? Would that be considered impersonating the project?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. as I mentioned below, reserving a crate name is allowed by these proposed rules if there is a linked repository where development activity can be verified.
I think this would have to be decided on a case-by-case basis after contacting the user and seeing the contents of what was published. I fear that having a fixed ruleset for such a situation would just cause this malicious user to look for the loophole in the ruleset and apply that. also, for context: the described situation has unfortunately happened a bunch of times over the past couple of months/years and is part of why we are proposing new policies that would allow us to potentially act in such cases.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It seems like specifically warning people against forking crates and publishing them under the original name might be helpful? The person who forked our crate also removed all the commit history and licensing, because they didn't understand either the legal or moral authorship requirements. So it seems like something that might need to be spelt out clearly and directly. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Removing licensing information means the crate "infringes any proprietary right of any party, including [...] copyright", so that's already clear cut in the proposal. (Using the name of a project as a crate name without the project's permission is definitely moving into trademark infringement territory, whether the trademark is registered or not, but that's admittedly a bit more nebulous, and a clear rule might be in order.)
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
It's technically true that we could have asked for a takedown from crates.io under this policy. But instead we submitted a PR to their repo with the correct license info, which they accepted. So it's clear cut, but perhaps not actually the desired first action?
Yes, I think a clear rule about project names and prefixes would be helpful. |
||
| crates.io, or by fraudulently misrepresenting your identity or site's purpose | ||
| - is related to inauthentic interactions, such as fake accounts and automated | ||
| inauthentic activity | ||
| - is using our servers for any form of excessive automated bulk activity, to | ||
| place undue burden on our servers through automated means, or to relay any | ||
| form of unsolicited advertising or solicitation through our servers, such as | ||
| get-rich-quick schemes | ||
| - is other automated excessive bulk activity and coordinated inauthentic | ||
Turbo87 marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| activity, such as | ||
| - spamming | ||
| - cryptocurrency mining | ||
| - is not functionally compatible with the cargo build tool (for example, a | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| "package" cannot simply be a PNG or JPEG image, a movie file, or a text | ||
| document uploaded directly to the registry) | ||
| - is abusing the package index for purposes it was not intended | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| You are responsible for using crates.io in compliance with all applicable laws, | ||
| regulations, and all of our policies. These policies may be updated from time to | ||
| time. We will interpret our policies and resolve disputes in favor of protecting | ||
| users as a whole. The crates.io team reserves the possibility to evaluate each | ||
| instance on a case-by-case basis. | ||
|
|
||
| For issues such as DMCA violations, or trademark and copyright infringements, | ||
| the crates.io team will respect the legal decisions of the | ||
| [Rust Foundation](https://rustfoundation.org/) as the official legal entity | ||
| providing the crates.io service. | ||
|
|
||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| ## Package Ownership | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| crates.io has a first-come, first-serve policy on crate names. Upon publishing a | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| package, the publisher will be made owner of the package on crates.io. | ||
|
|
||
| If you want to take over a package, we require you to first try and contact the | ||
| current owner directly. If the current owner agrees, they can add you as an | ||
| owner of the crate, and you can then remove them, if necessary. If the current | ||
| owner is not reachable or has not published any contact information the | ||
| crates.io team may reach out to help mediate the process of the ownership | ||
| transfer. | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| The crates.io team only deletes crates from the registry that do not comply with | ||
| the policies on this document. Crate deletion by their owners is not possible to | ||
| keep the registry as immutable as possible. If you want to flag your crate as | ||
| open for transferring ownership to others, you can publish a new version with | ||
| a message in the README or description communicating to the crates.io support | ||
| team that you consent to transfer the crate to the first person who asks for it: | ||
|
|
||
| > I consent to the transfer of this crate to the first person who asks | ||
| > [email protected] for it. | ||
Turbo87 marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
|
|
||
| ## Data Access | ||
|
|
||
| If you need access to a large subset of the crates.io database we recommend | ||
| first looking at the **crates.io [index repository](https://github.com/rust-lang/crates.io-index)**. | ||
| This repository is updated live whenever new versions are published and contains | ||
| all the information needed for cargo to run the dependency resolution algorithm. | ||
|
|
||
| In case the index dataset is insufficient for your purposes, we also publish a | ||
| **database dump** every 24 hours. This includes the majority of data from our | ||
| database except for sensitive private information. The latest database dump is | ||
| available at <https://static.crates.io/db-dump.tar.gz> and information on using | ||
| the content is contained in the tarball. Please note that while we aim to keep | ||
| the data structure somewhat stable, we can not give any stability guarantees on | ||
| the exact database table layouts. | ||
|
|
||
| If the index repository and the database dump are insufficient you may also use | ||
| the crates.io API directly, though it is at the discretion of the crates.io to | ||
| block any excessive usage. We require users of the crates.io API to limit | ||
| themselves to a maximum of 1 request per second. | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| We also require all API users to provide a user-agent header that allows us to | ||
| uniquely identify your application. This allows us to more accurately monitor | ||
| any impact your application may have on our service. Providing a user agent that | ||
| only identifies your HTTP client library (such as `request/0.9.1`) increases the | ||
| likelihood that we will block your traffic. | ||
|
|
||
| It is recommended, to include contact information in your user-agent header: | ||
|
|
||
| - Bad: `User-Agent: reqwest/0.9.1` | ||
| - Better: `User-Agent: my_bot` | ||
| - Best: `User-Agent: my_bot (my_bot.com/info)` or `User-Agent: my_bot (help@my_bot.com)` | ||
|
|
||
| This allows us to contact you if we would like a change in your application's | ||
| behavior without having to block your traffic. | ||
|
|
||
| We reserve the right to block traffic from any client that we determine to be in | ||
| violation of this policy or causing an impact on the integrity of our service. | ||
|
|
||
|
|
||
| ## Security | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| Safety is one of the core principles of Rust, and to that end, we would like to | ||
| ensure that cargo and crates.io have secure implementations. To learn more about | ||
| disclosing security vulnerabilities for these tools, please reference the | ||
| [Rust Security policy](https://www.rust-lang.org/policies/security) for more | ||
| details. | ||
|
|
||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| Note that this policy only applies to official Rust projects like crates.io and | ||
| cargo, and not individual crates. The crates.io team and the Security Response | ||
| working group are not responsible for the disclosure of vulnerabilities to | ||
| specific crates, and if any issues are found, you should seek guidance from | ||
| the individual crate owners and their specific policies instead. | ||
|
|
||
| Thank you for taking the time to responsibly disclose any issues you find. | ||
|
|
||
|
|
||
| ## Violations and Enforcement | ||
|
|
||
| crates.io retains full discretion to take action in response to a violation of | ||
| these policies, including account suspension, account termination, or removal of | ||
| content. | ||
|
|
||
| We will however not be proactively monitoring the site for these kinds of | ||
| violations, but instead relying on the community to draw them to our attention. | ||
|
|
||
| While the majority of interactions between individuals in the Rust community | ||
| falls within our policies, violations of those policies do occur at times. | ||
| When they do, the crates.io team may need to take enforcement action to address | ||
| the violations. In all cases, content and account deletion is permanent and there | ||
| is no basis to reverse these moderation actions taken by the crates.io team. | ||
Turbo87 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| Account suspension may be lifted at the team's discretion however, for example in | ||
| the case of someone's account being compromised. | ||
|
|
||
|
|
||
| ## Credits & License | ||
|
|
||
| This policy is partially based on [PyPI’s Acceptable Use Policy](https://github.com/pypi/warehouse/blob/3c404ada9fed7a03bbf7c3c74e86c383f705d96a/policies/acceptable-use-policy.md) | ||
| and modified from its original form. | ||
|
|
||
| Licensed under the [Creative Commons Attribution 4.0 International | ||
| license](https://creativecommons.org/licenses/by/4.0/). | ||
|
|
||
| ------------------------------------------------------------------------------- | ||
|
|
||
| # Prior art | ||
| [prior-art]: #prior-art | ||
|
|
||
| As the "Credits & License" says, the main inspiration for the proposed policy is the [Acceptable Use Policy](https://pypi.org/policy/acceptable-use-policy/) of the Python Package Index (PyPI). Their policy in turn is based on the [Acceptable Use Policies](https://docs.github.com/en/site-policy/acceptable-use-policies/) of GitHub. Both of these policies are licensed under the [Creative Commons Attribution 4.0 International license](https://creativecommons.org/licenses/by/4.0/), so we can happily reuse them. | ||
|
|
||
| [PEP 541](https://peps.python.org/pep-0541/) (Python Enhancement Proposal) was also mixed into the document above, specifically the [Invalid Projects](https://peps.python.org/pep-0541/#invalid-projects) section. | ||
|
|
||
| The third source of material are the "[Open-Source Terms](https://docs.npmjs.com/policies/open-source-terms)" from npm, from which a few more rules on "Acceptable Content" were imported. | ||
|
|
||
| RubyGems, Maven Central, Packagist (PHP) and Nuget (C#) were also investigated, but they did not appear to have written rules published in easy-to-find places. | ||
|
|
||
|
|
||
| # Unresolved questions | ||
| [unresolved-questions]: #unresolved-questions | ||
|
|
||
| - Is the wording of the "name reservation" clause sufficient to discourage name squatting in the future? | ||
| - Are there any current legitimate uses of crates.io that would suddenly be forbidden by these new rules? | ||
|
|
||
| # Future possibilities | ||
| [future-possibilities]: #future-possibilities | ||
|
|
||
| - [PEP 541](https://peps.python.org/pep-0541/) also defines rules for abandoned projects and how people could continue maintenance for them. Introducing something like that would be a large deviation for crates.io though, and something that would need a dedicated RFC. Nevertheless, it is worth thinking about if the majority of the Rust community would prefer having such a ruleset. | ||
Uh oh!
There was an error while loading. Please reload this page.