This is so wildly against the Rust stability ethos I almost laughed out loud on the bus.
This is already "solved", as we now require email verification before publishing a crate.
That's actually my point — someone updating the crate would have to have an email on hand so people can at least attempt contact.
My point is, it's so easy to work around this policy that it accomplishes nothing in the long term, other than maybe only removing the crates of swmon. At that point a policy "You shouldn't be swmon to register crates" would be as (or probably more) effective.
I mean, I wouldn't personally be opposed to that 
Are you suggesting the crates.io team should review each non-empty uploaded crate, or am I missing something?
Not at all. What I was trying to say was that if a partially-automated process determines that a crate is squatted (which is fallible, as has been mentioned by @sgrif), a human could then be put in the loop to determine for sure if someone tries to claim the squatted name.
1 Like
[this is not the opinion of the crates.io team]
Yeah but for people who intentionally squat it wouldn't change anything, as they could just not reply.
Honestly, I don't think a policy so weak it can hopefully be enforced against a single user is a productive use of the community's time. eRFC 2614 implements the "I'll know it when I see it" approach to transferring crate ownership, and I'd love to see the efforts here directed torwards moving it to the finishing line.
Misunderstood you, sorry! 
Still, it can be a lot of work for the team, and we're constrained in resources already.
Yeah but for people who intentionally squat it wouldn't change anything, as they could just not reply.
That would fall under point 3. If someone can be reached but doesn't respond within a month, permission is basically assumed. They would have to actively say no.
Honestly, I don't think a policy so weak it can hopefully be enforced against a single user is a productive use of the community's time. eRFC 2614 implements the "I'll know it when I see it" approach to transferring crate ownership, and I'd love to see the efforts here directed torwards moving it to the finishing line.
Of course; my comment was in jest. I'd like to see that eRFC move forward as well. I'm not sure what exactly is necessary there — I haven't looked through all the comments yet.
Misunderstood you, sorry!
I obviously can't predict how many people will try to claim crates that can pass the preliminary, automated test. However, it would be feasible to determine roughly how many crates fall under these criteria. Is there a public API and/or data dump of crates.io data? I'd be interested in writing a script to go through to see what crates (and how many) would be considered "squatted".
How would a script know if a crate has been reserved for an existing project? I reserved a crate for an already existing project of mine, I might want to publish on crates.io in the future.
The script should detect that as squatting because it is squatting. It might be defensible, but it’s still fair to call it squatting.
2 Likes
As indicated by the original post, it would only apply if it was published at least six months ago. If you've been holding onto a name for over six months and haven't published something useful, IMO it should be allowed to be transferred if you don't respond.
1 Like
Random maybe-new idea: What if crates.io had a "reserve name" feature, but the reservation auto-expires after 3 months (or whatever) if you never actually publish a crate by that name? That would make it fairly self-evident what "squat length" is considered acceptable, and lets what I assume is the largest group of benign squatters self-identify as such.
1 Like
still thank you for it, I always use it for recommendations when comparing alternatives
I thought of that as well. It would be a sensible solution going forward, but we'd still need to address the names already squatted.
Hmm... actually, what if we did implement a blacklist? Misbehaving users get banned and their crates unregistered... Not sure how effective that would be, but hopefully it would at least discourage bad behavior?
I still think someone should write up a summary doc...
1 Like
I haven’t seen any consensus in this thread nor in others that any squatting/name spacing/etc change would be retroactively applicable.
1 Like
I agree! I’m coming around on the idea raised very early in this thread that threads like this might be better off locked until they have something like this.
3 Likes
I think there are certain hotbutton "discussed to death" topics which could definitely benefit from a concise history of past discussions which you keep asking for and I sure hope someone writes!
When one of these comes up and it doesn't have a concise history of past discussion, it would be amazingly helpful if people who truly want to see it through would do the work to summarize and document the discussion.
Otherwise every time I see a thread like this, I feel like we're retracing steps in the sand. They wind up being very frustrating to everyone involved, and may be off-putting to people who genuinely want to do the work to see a particular idea through.
4 Likes
I have put forward a sensible minimum. Are there any specific problems you have with it? Pretty much all you've brought up (off the top of my head) is a security concern that hasn't been justified.
Given my many attempts to reiterate several issues which I feel like aren't being addressed or are being completely ignored, I am going to gracefully bow out of this thread as I don't feel like continued participation is helpful at this point.
1 Like
All I was seeking was clarification on how publishing something after having an empty crate is a security issue. You claim I ignored that, yet never explained how it was an issue.
The downside is that if you lose the private key, you cannot release updates, ever, and neither can anyone else.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.