# Pre-RFC: Formal squatting policy on crates.io **URL:** \ **Category:** Uncategorized\ **Created:** [November 15, 2019, 8:57pm UTC](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302 "2019-11-15T20:57:04Z")\ **Posts on this page:** 20\ **Page:** 3
**Author:** ![jhpratt](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jhpratt/32/11640_2.png) [@jhpratt](https://internals.rust-lang.org/u/jhpratt)\ **Post date:** [November 19, 2019, 1:11am UTC](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302/44 "2019-11-19T01:11:23Z")
Does anyone have an issue with the "I'll know it when I see it" idea brought up in this thread? I don't think I've seen any explicit disagreement to that one. ---
**Author:** ![Tom-Phinney](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/tom-phinney/32/3299_2.png) [@Tom-Phinney](https://internals.rust-lang.org/u/Tom-Phinney)\ **Post date:** [November 19, 2019, 1:14am UTC](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302/45 "2019-11-19T01:14:17Z")
The problem with your question is that it addresses a very small audience: those who are focused on Rust feature development – thus are reading this forum – and who care enough about the problem to be reading this thread. A poll of Rustaceans at large would be needed to get a fair answer to your question. ---
**Author:** ![anp](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/anp/32/6036_2.png) [@anp](https://internals.rust-lang.org/u/anp)\ **Post date:** [November 19, 2019, 1:16am UTC](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302/46 "2019-11-19T01:16:57Z")
I do have an issue with the criteria. Is there any evidence that enforcing these would have a meaningfully positive impact? Has anyone volunteered to help enforce the rules? ---
**Author:** ![chrisd](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/chrisd/32/7232_2.png) [@chrisd](https://internals.rust-lang.org/u/chrisd)\ **Post date:** [November 19, 2019, 1:38am UTC](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302/47 "2019-11-19T01:38:01Z")
> [@XAMPPRocky](#): > > None of these proposals ever provide why a person would deserve to get these names. There seems to be an expectation among the people asking for a squatting policy that because someone isn't using the crate in the way you want, you should be able to re-purpose it for their own use. I think this is mischaracterises the issue some people have. There are crates that a) contain no usable code and b) whose authors are not contactable. And both conditions have been true for years. I don't know if this is a major issue or merely an annoyance but either way it's unhelpful to overstate what people are saying or speculate about perceived motives. ---
**Author:** ![bascule](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/bascule/32/3057_2.png) [@bascule](https://internals.rust-lang.org/u/bascule)\ **Post date:** [November 19, 2019, 2:35am UTC](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302/48 "2019-11-19T02:35:32Z")
> [@XAMPPRocky](#): > > NPM has infinitely more packages than [crates.io](http://crates.io) (or any other package repository) and name-squatting is not a problem that is brought up with the same frequency (or really at all). NPM is a VC-funded startup company with a full-time staff who are paid to work on these problems. [Crates.io](http://Crates.io) receives some community resources, but the people who work on it day-to-day are largely (maybe even entirely?) volunteers. I'll also note I'm still very interested in collaborating on end-to-end cryptographic security for crates, and this kind of mechanism is one it'd be really nice to add _after_ such a security mechanism is in-place, rather than before: > > > The fun thing about packaging systems with central package directories is the ce…ntral package directories have this annoying tendency to be compromised. There have been a few such notable compromises in recent history, such as RubyGems and npm. Fortunately no serious problems resulted in either of these attacks they were both detected early, but a more sinister attack could go undetected, poisoning the package repository and spreading malware. > > One way to stop this is to move the source of authority for the integrity of packages from the package repository to the developers of packages. However, managing keys is hard, and many people simply won't want to do this. Furthermore, you have to worry about how to retrofit the existing packages into this model if your packaging system didn't launch with developer-managed keys from day one (which Cargo didn't) > > There's a system that solves all these problems called The Update Framework (TUF), collaboratively developed by both Tor developers and academics: > > http://theupdateframework.com/ > > The Update Framework allows developers to opt-in to managing their own keys. High profile packages can be signed by developers: specifically, TUF supports "threshold signatures" so k / n developers are needed to countersign a package in order for it to count as released. However, not everyone is forced to manage their own keys: people who don't want to can have their packages signed by the package repository instead. > > TUF secures developer keys by having developers who own "unclaimed" packages request to associate some signing keys with them. A system administrator then periodically (once a week or other tolerable time interval) signs these developer keys with an offline key (or keys, TUF uses threshold signatures everywhere). At this point, these packages move from "unclaimed" to "claimed", and become what TUF calls a "delegated target": the developers, not the packaging system, become the source of truth for that particular package. > > For more information, I suggest you read their paper "Survivable Key Compromise In Software Update Systems": > > http://freehaven.net/~arma/tuf-ccs2010.pdf > > I think a system like TUF can easily be retrofitted to Cargo as it exists today. There are a few changes I might recommend before you try to add TUF, but I think you're off to a good start. > > However, if you did want to use something like TUF, it does figure into the overall AuthZ model of the system. There are a number of outstanding AuthZ issues / suggestions like #48 and #58. If you do want to integrate a system like TUF where developers manage their own keys, it will definitely influence whatever AuthZ model you adopt, because TUF moves things like authorization and integrity partly to the client. > > I worked on adding TUF to RubyGems at one point and liked it, although we never finished. The people behind it worked on adding it to PyPI, and were very helpful with our efforts to add it to RubyGems. It's still supportable, and in fact a built-in mechanism of the proposed solution in that link (threshold signatures), but it's one it'd be nice to have from the start, rather than trying to retrofit cryptographic security around an established anti-squatting process. ---
**Author:** ![kornel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kornel/32/2711_2.png) [@kornel](https://internals.rust-lang.org/u/kornel)\ **Post date:** [November 19, 2019, 3:23am UTC](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302/49 "2019-11-19T03:23:15Z")
> What is the proof this is not scalable? To clarify, by that "not scalable" I've meant it's tolerable if few crates do this, but not if most crates do this. I've shown a mockup of how top crates-io crates would look like if everyone used "nokogiri"-like naming scheme. To me this mockup looks shockingly bad. > because someone isn't using the crate in the way you want That's an overly broad characterization. The issue is about a specific kind of misuse. > NPM has infinitely more packages than [crates.io](http://crates.io) (or any other package repository) and name-squatting is not a problem that is brought up with the same frequency Exactly. That's because npm _has_ an anti-squatting policy, and enforces it! npm has more resources to throw at the problem, so crates-io can't commit to do the same. But I'm very disappointed that crates-io takes the completely opposite position of giving up and condoning squatting. You don't need millions in VC money to write "Please don't squat" in the rules. The community can't help writing tools and volunteering to enforce the policy if the crates-io team doesn't agree that's a problem worth addressing in the first place. ---
**Author:** ![skade](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/skade/32/3333_2.png) [@skade](https://internals.rust-lang.org/u/skade)\ **Post date:** [November 19, 2019, 11:07am UTC](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302/50 "2019-11-19T11:07:04Z")
> [@jhpratt](#): > > Most recent publish at least six months ago. If combined with a possible public repository, this would indicate lack of development. This is a bad rule. My first ever crate `leveldb` is effectively unmaintained, yet used in quite some production systems, such as vector. It has seen no released for longer stretches, but it being an glue layer above `leveldb-sys` (which also does not see updates but a build system fix here and there), this is also okay. Being done does not constitute squatting. > [@jhpratt](#): > > Crate owner cannot be reached, or was reached and did not respond within one month. This is an equally useless rule. Being unreachable does not constitute squatting. Software, especially crates, should be allowed to become unmaintained and legacy and remain accessible to the users. If I became unreachable (for whatever reason) and someone were to argue the [crates.io](http://crates.io) team into handing over access to my crate, this is a serious attack vector into some infrastructure systems. ---
**Author:** ![skade](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/skade/32/3333_2.png) [@skade](https://internals.rust-lang.org/u/skade)\ **Post date:** [November 19, 2019, 11:30am UTC](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302/51 "2019-11-19T11:30:37Z")
> [@kornel](#): > > npm has more resources to throw at the problem, so crates-io can't commit to do the same. But I'm very disappointed that crates-io takes the completely opposite position of giving up and condoning squatting. You don't need millions in VC money to write "Please don't squat" in the rules. The community can't help writing tools and volunteering to enforce the policy if the crates-io team doesn't agree that's a problem worth addressing in the first place. The NPM squatting policy not very fleshed out and applied manually, so _yes_, you do need a support team to decide. The same rule applies to [crates.io](http://crates.io) already: the [crates.io](http://crates.io) maintainers _reserve the right_ to remove packages. The squatting policy of NPM also isn't a particularly good example: The Disputes Policy refers to the Terms of Use: [npm Open-Source Terms | npm Docs](https://www.npmjs.com/policies/open-source-terms#acceptable-content) The Terms of Use then refer back to the Acceptable Use Policy for Details: [Dispute Resolution | npm Docs](https://www.npmjs.com/policies/disputes#squatting) With the final rule being: "You can send us an email, we may do stuff" That's a very elaborate way of writing that ;). I also don't agree with your framing of "team vs. community", but YMMV. ---
**Author:** ![chrisd](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/chrisd/32/7232_2.png) [@chrisd](https://internals.rust-lang.org/u/chrisd)\ **Post date:** [November 19, 2019, 12:36pm UTC](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302/52 "2019-11-19T12:36:10Z")
But both of those criteria depend on the crates also being: > [@jhpratt](#): > > Unquestionably useless — zero useful behavior. A trivial check for this is if there are no public exports. `leveldb`, for example, has public exports. ---
**Author:** ![newpavlov](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/newpavlov/32/3290_2.png) [@newpavlov](https://internals.rust-lang.org/u/newpavlov)\ **Post date:** [November 19, 2019, 12:40pm UTC](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302/53 "2019-11-19T12:40:21Z")
> [@skade](#): > > Being done does not constitute squatting. It's easy to imagine that a "done" crate will become sub-optimal after a certain time. It can be new language idioms, bug fixes to compiler may make crate uncompilable, an upstream dependency may break and influence downstream code, etc. With the current policy after maintainer disappearance crates are left to rot for eternity, which I don't think is healthy for the ecosystem in a long run. > [@skade](#): > > If I became unreachable (for whatever reason) and someone were to argue the [crates.io](http://crates.io) team into handing over access to my crate, this is a serious attack vector into some infrastructure systems. This problem can be easily solved by restricting versions which can be published after crate transfer, i.e. the reciever will not be able to publish patch/minor updates to existing crate versions, so `cargo update` will not pull versions managed by a new owner without manually editing `Cargo.toml`. This was discussed briefly in my [proposal](https://internals.rust-lang.org/t/8668). > [@skade](#): > > The same rule applies to [crates.io](http://crates.io) already: the [crates.io](http://crates.io) maintainers _reserve the right_ to remove packages. No, it does not. [crates.io](http://crates.io) team only uses it for crates with malicious code and potentially for complying with trademark complaints, while NPM also uses this right to fight with unhealthy squatting. Python world also sees rotting packages as a problem, see [PEP 541](https://www.python.org/dev/peps/pep-0541/). ---
**Author:** ![djc](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/djc/32/1592_2.png) [@djc](https://internals.rust-lang.org/u/djc)\ **Post date:** [November 19, 2019, 1:50pm UTC](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302/54 "2019-11-19T13:50:19Z")
> [@jhpratt](#): > > Does anyone have an issue with the "I'll know it when I see it" idea brought up in this thread? I don't think I've seen any explicit disagreement to that one. Basically that ends up being [eRFC: Crate name transfer by dtolnay · Pull Request #2614 · rust-lang/rfcs · GitHub](https://github.com/rust-lang/rfcs/pull/2614). ---
**Author:** ![XAMPPRocky](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/xampprocky/32/6049_2.png) [@XAMPPRocky](https://internals.rust-lang.org/u/XAMPPRocky)\ **Post date:** [November 19, 2019, 1:56pm UTC](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302/55 "2019-11-19T13:56:27Z")
> [@chrisd](#): > > I think this is mischaracterises the issue some people have. There are crates that a) contain no usable code and b) whose authors are not contactable. And both conditions have been true for years. I am aware, this still doesn't provide what benefit there would be to taking these crates. > [@kornel](#): > > You don't need millions in VC money to write "Please don't squat" in the rules. The community can't help writing tools and volunteering to enforce the policy if the crates-io team doesn't agree that's a problem worth addressing in the first place. Tooling will not solve a fundamentally human problem, and neither would volunteers, the best an outside volunteer could do is flag a crate, which still leaves the work and responsibility to another member. All of these "solutions" require more work, yet they don't address where the time for this work will come from. Creating these policies are very easy when you're not the person who will actually be responsible for implementing, maintaining, and responsible for it when there is disputes. Why should [crates.io](http://crates.io) team who volunteer their time stretch themselves thinner, and handle more moderation work for little to no reward? For any kind of policy to succeed it needs to come with the collaboration of the [crates.io](http://crates.io) team. ---
**Author:** ![chrisd](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/chrisd/32/7232_2.png) [@chrisd](https://internals.rust-lang.org/u/chrisd)\ **Post date:** [November 19, 2019, 2:09pm UTC](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302/56 "2019-11-19T14:09:51Z")
> [@XAMPPRocky](#): > > I am aware, this still doesn't provide what benefit there would be to taking these crates. Which is a fair criticism. And of course the flip side of that is what cost/benefit there is to allowing a small number of `crates.io` users to act as ad-hoc gatekeepers to a large number of crate names. But my main issue is that if this conversation is to be at all productive it does need to stay on topic and not argue against things that are not being proposed. Otherwise everyone ends up talking past each other. ---
**Author:** ![jhpratt](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jhpratt/32/11640_2.png) [@jhpratt](https://internals.rust-lang.org/u/jhpratt)\ **Post date:** [November 19, 2019, 2:31pm UTC](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302/57 "2019-11-19T14:31:15Z")
I don't think I was clear: _all_ of those criteria would need to match, not just one. So if the owner could be reached and declined a transfer, that would be the end of it, even if it's otherwise relatively clear. Like I said, this is a baseline. ---
**Author:** ![Aaron1011](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/aaron1011/32/2246_2.png) [@Aaron1011](https://internals.rust-lang.org/u/Aaron1011)\ **Post date:** [November 19, 2019, 3:54pm UTC](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302/58 "2019-11-19T15:54:48Z")
> [@newpavlov](#): > > With the current policy after maintainer disappearance crates are left to rot for eternity, which I don't think is healthy for the ecosystem in a long run. I strongly disagree. If the maintainer decides to transfer ownership, that's one thing. However, I don't think we should allow takeover of existing crates by (essentially) arbitrary third parties. I frequently run [cargo upgrade](https://github.com/killercup/cargo-edit#cargo-upgrade), but this change would require me to verify that all of my dependencies haven't been transmuted into completely different crates. I think the benefits of having crates not change out from under people's feet vastly outweigh the benefits of making certain crates names accessible. ---
**Author:** ![newpavlov](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/newpavlov/32/3290_2.png) [@newpavlov](https://internals.rust-lang.org/u/newpavlov)\ **Post date:** [November 19, 2019, 7:44pm UTC](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302/59 "2019-11-19T19:44:07Z")
> [@Aaron1011](#): > > I frequently run [cargo upgrade](https://github.com/killercup/cargo-edit#cargo-upgrade), but this change would require me to verify that all of my dependencies haven't been transmuted into completely different crates. Do you use for breaking upgrades as well? If crate had a breaking release (e.g `v0.1.0` -\> `v0.2.0` or `v1.0.0` -\> `v2.0.0`), you should check changes in the crate either way. And with the mentioned restrictions on versions which can be published after crate transfer you will notice it, so crates with this proposal will not "change out from under people's feet". If you still think such measures are insufficient, we also could add additional barriers for using crate after transfer, e.g. we could add `owner` field without which you will not be able to use post-transfer versions: ```rust foo = { version = "0.7", owner = "new_owner" } ``` ---
**Author:** ![jhpratt](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jhpratt/32/11640_2.png) [@jhpratt](https://internals.rust-lang.org/u/jhpratt)\ **Post date:** [November 19, 2019, 8:28pm UTC](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302/60 "2019-11-19T20:28:04Z")
And what if the current owner cannot be reached, the crate is empty, _and_ has been so for a period of time? There's zero risk of breakage there. ---
**Author:** ![Aaron1011](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/aaron1011/32/2246_2.png) [@Aaron1011](https://internals.rust-lang.org/u/Aaron1011)\ **Post date:** [November 19, 2019, 8:31pm UTC](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302/61 "2019-11-19T20:31:06Z")
Personally, I'd be fine with that, as long it was never possible to have actually used the crate. What I object to is changing the ownership of existing non-empty crates (e.g. a crate which someone could actually have used) without involving the owner. ---
**Author:** ![jhpratt](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jhpratt/32/11640_2.png) [@jhpratt](https://internals.rust-lang.org/u/jhpratt)\ **Post date:** [November 19, 2019, 8:45pm UTC](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302/62 "2019-11-19T20:45:14Z")
Just so you know, that's my original proposal 🙂 ---
**Author:** ![kornel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kornel/32/2711_2.png) [@kornel](https://internals.rust-lang.org/u/kornel)\ **Post date:** [November 20, 2019, 12:04am UTC](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302/63 "2019-11-20T00:04:50Z")
> [@XAMPPRocky](#): > > All of these "solutions" require more work, We haven't really got deep into discussing solutions and their costs, because the mere idea of doing anything gets shot down quickly. And not-yet-presented solutions are shot for having too large cost on crates-io team, without even knowing what that is! So here's one zero-cost solution: Change crates-io policy to say that squatting is frowned upon. Literally just a wording change in one doc. Currently, a large portion of squatted crates is taken by well-meaning people (these "please contact me if you want this" crates). They're unlikely to be stubborn rule-breakers running a sophisticated trolling-for-profit operation. They've just grabbed a bunch of names, because that is explicitly allowed by crates-io, very easy to do, and has no downsides for the squatter. And solution to this may be as simple as politely asking them not to do that. edit: changed that to [Proposal for crates-io crate name reservation](https://internals.rust-lang.org/t/proposal-for-crates-io-crate-name-reservation/11341) [Previous page](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302.md?page=2) [Next page](https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302.md?page=4)