Skip to content
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

Limit the number of crates one user account can own, with per-user overrides #6436

Open
carols10cents opened this issue May 5, 2023 · 11 comments
Labels
A-accounts B-needs-investigation C-enhancement ✨ Category: Adding new behavior or a change to the way an existing feature works

Comments

@carols10cents
Copy link
Member

Currently, a user can theoretically own an infinite number of crates, as long as they stay under the new crate publish rate limit.

We could limit the blast radius of some spamming by limiting all user accounts by default to a concrete number of crates. We should look at the number of crates users currently own and pick a value that covers something like 99% of current users.

Before enforcing this, we should have a per-user-account mechanism to set a higher limit for particular users (the 1% that would currently be over the limit, although we could leave those as-is and they just would immediately be prevented from creating more crates, this needs to not cause any errors though), like we have for max upload size and new crate burst increases so that people with legitimate needs could contact us and explain the situation to get an increase.

@carols10cents carols10cents added C-enhancement ✨ Category: Adding new behavior or a change to the way an existing feature works A-accounts labels May 5, 2023
@LawnGnome
Copy link
Contributor

I quickly threw together some numbers for users (for now, I'm excluding teams).

No huge shocks in terms of what the distribution of the number of crates owned by a user looks like:

image

Percentiles of the number of crates owned by a user:

25th percentile: 1
50th percentile: 2
80th percentile: 4
90th percentile: 8
99th percentile: 42

Raw numbers of users with at least n crates:

Number of users with at least 20 crates  :  975 (3.4% of all users)
Number of users with at least 50 crates  :  205 (0.7% of all users)
Number of users with at least 100 crates :   66 (0.2% of all users)
Number of users with at least 200 crates :   20 (0.1% of all users)
Number of users with at least 500 crates :    3 (0.0% of all users)

I'd probably suggest setting the initial limit at 50?

@Eh2406
Copy link
Contributor

Eh2406 commented May 5, 2023

(I am not on a crates.io team, but) I would suggest that the limit could in fact be lower than 50. Some of those 200 users are spam accounts that have since been shut down, others are users who should be given a exception from the very beginning no matter what limit we pick. Now that I've said that I see the critical word initial, 50 seems like a good place to start to see if all the systems are working correctly with plans to lower it after initial testing.

@ToBinio
Copy link
Contributor

ToBinio commented May 6, 2023

I don't know if I am the only one, but publishing something on crates.io already feels kinda "scary". simply because of the permanent nature of crates.io.
I do believe adding another limitation and making every single publish be even more important feels very uncomfortable.
simply because the rust-std library is very small and so rust heavily requires active crates development. Making the entry border for such development harder could in my opinion harm the ecosystems.

Don't get me wrong, I am 100% pro doing something against crate-spamming.

but maybe there should be some possibility for removing a crate you already publish so it does not count toward the limit. I am not talking about a 100% deletion system but maybe you can mark a crate as "free to take" and then anybody who wants the name could take it. this would create some sort of second-hand shop for crate names.

@LeoniePhiline

This comment was marked as off-topic.

@carols10cents
Copy link
Member Author

@LeoniePhiline Please report these to [email protected]; this is not the appropriate venue. Thanks!

@epage
Copy link

epage commented Jul 21, 2023

rust-lang/rfcs#3452 would take a tiny bit of pressure off of crate counts.

With rust-lang/rfcs#3243, would the cap be for top-level names?

@carols10cents
Copy link
Member Author

With rust-lang/rfcs#3243, would the cap be for top-level names?

Exactly, with crates-as-namespaces, we'd make the top-level name cap pretty low and then sub-crates very high or unlimited.

@Turbo87
Copy link
Member

Turbo87 commented Jun 22, 2024

@carols10cents I've been thinking about bit about this proposal, but I'm not sure how it would work in relation to crate ownership transfers. If a spammer has two accounts they could transfer the spam crates from account A to B and once that is done account A can publish the next set of X crates. I guess this would only work if we disallowed crate transfers to account B once that account reaches the limit, but I'm not sure how I feel about that 🤔

any thoughts on this?

@carols10cents
Copy link
Member Author

carols10cents commented Jun 24, 2024

@Turbo87 That seems like a lot of work that a spammer would be unlikely to undertake? And I don't understand why the transferring is necessary? If the spammer has 2 accounts, they can publish 2X crates, 1X from each account...

I would say ownership of crates is ownership of crates, whether you published them initially or they were transferred to you, so they would count towards the limit.

@Turbo87
Copy link
Member

Turbo87 commented Jun 25, 2024

I would say ownership of crates is ownership of crates, whether you published them initially or they were transferred to you, so they would count towards the limit.

so you would block ownership transfers once the limit has been reached?

@carols10cents
Copy link
Member Author

so you would block ownership transfers once the limit has been reached?

Yes.

Another thing I was thinking about was this limit could change in relation to the age of the account-- say, you may own 10 crates per year that your crates.io account has existed. Spammers would be unlikely to have that kind of patience, but people who continue to contribute over time would be trusted with more abilities.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-accounts B-needs-investigation C-enhancement ✨ Category: Adding new behavior or a change to the way an existing feature works
Projects
None yet
Development

No branches or pull requests

7 participants