Crates.io incident 2018-10-15


#24

The issue is taken seriously, though, just the conclusions don’t match with a very vocal subset of the community.

And getting hazardous about the whole thing like the person causing this incident won’t help moving this issue.

(for the record, I vehemently oppose namespacing)


#25

I’m seriously baffled by the amount of what I would call “victim blaming” in this thread. I someone does something which is not acceptable, saying “yeah but you had it coming” is not a great way to react.

There was a denial of service attack on the community. A solution for damage limitation was proposed years before the attack and not accepted and now the attack happened. They are related and interlocked.

Thankfully we haven’t yet had malicious typo-squatting yet with tokyo-core adding a dev-dependency on sys32-encoding (or other extremely dry name that makes you assume it’s super important) which in turn opens a socket in the build.rs and sends data from your build machine to a 3rd party.

This is also a related issue to spamming and namespacing and important enough to impact the design of the crate system and infrastructure.

It’s ok that Cargo’s design made a mistake here. We can fix it. Just default all packages to imply org::rust_lang::legacy. Make a rustfmt rule to fix up packages as we go. Eventually namespaces get introduced, etc.

(Also: I’m all for federation!)


#26

Agree that victim blaming isn’t helpful, and I also agree that the policy around spam reserving crates needs to be addressed, instead of being ignored.

The ability for mass reservation of crate names, even going so far as implying you need to buy the rights from the owner similar to domain name squatting, is one of my biggest disappointments with rust and the ecosystem so far (the language itself is great!).

People like https://crates.io/users/swmon are part of the problem.

As a plea from someone coming from AAA game development and the black pit of C++, please deal with this. One of the biggest strengths of the rust ecosystem is a proper package management and module system, so it is important to spend the effort in protecting and advancing it.


#27

Here’s the blog post https://blog.rust-lang.org/2018/10/19/Update-on-crates.io-incident.html


#31

From the blog post, my impression is that this was very professionally handled. Nice work!

I’m sure you have already considered this, but in case you have not, I would suggest providing a FAQ like the rust-lang one: https://www.rust-lang.org/en-US/faq.html, with some of these policy questions. This might reduce some of the tension.

I don’t think this thread or other recent ones constitute consensus on what the community wants.


#32

So, I think that you wanted something different from this post. The point of the post wasn’t to try to discuss the overall problem; it was to talk specifically about the incident. For example:

We can’t actually know that the person who did this did so because of the namespacing discussion. As such, getting into it is not really relevant.


But, getting into the other bits:

The rationale is in the post. Was that not clear, or is this a typo (“wondered”, maybe?)

As the post says;

If you feel that a policy is problematic, the correct place to propose a change is by creating an RFC or messaging the team at help@crates.io.

Discussing it is fine, but discussions here are never going to change policy. In that sense, it is a “waste”, but that’s because discussions here are usually precursors for RFCs, so that’s also not a “waste” in the other sense.

I agree that it’s felt adversarial for a long time, but on a personal note, please consider how your framing here promotes that adversity:

Some of the community has. Much of the community has not. There were official responses, early in the discussions, but then it got fairly nasty, and most people on the “anti” side got tired of going in circles. The “pro” side has constantly promoted this “community vs the team” mentality, when the community is significantly more fragmented than they suggest. And, since this is only internals, and not an RFC, if I only have a limited time and energy, I’m going to save it for the venue where it’s possibly going to affect real policy. I also don’t feel that any new arguments have been made since 2014.

I do not know how to fix this rift. I don’t feel the pro side is ever going to accept any of the arguments.


#33

No. There’s large groups in “the community” that don’t see namespacing as a solution. Trying to use the voice of the mass doesn’t help here.


#34

I actually thought that https://crates.io/policies contained the same text as my 2014 post until yesterday. I certainly agree that it should be more prominent.


#36

I am not saying that there is equal support. I am saying that we do not know what percent is on what side.

Sorry, maybe I’m making a mistake, but I don’t know what you’re referring to. Could you point me to this? It’s been hard to keep track of all of the responses, but I can’t remember what you’re talking about.


#38

What makes you sure here, any data on that? I personally am opposed, but I’ve never said anything in any discussion.


#39

The only recent comment I can recall by anyone in the team was @sgrif, who said

Emphasis mine. There have been 34 posts since that comment as well, which doesn’t seem like shutting something down to me.


#41

It’s okay, it happens.


#42

I’d like to point out that this also contributes to this being adverserial. “Some” versus “Much”. I’d also like to add that I’m on the pro side, but am also tired of going in circles. It’s also a reason I try not to participate much in language/ecosystem discussions anymore.

Can you clarify this? This seems to be putting people squarely into two camps. But I think there are actually many sides. As in, people have different reasons for wanting namespaces, and different amounts of disagreements with the presented arguments.

Besides, this discussion isn’t going to end. A community is made up of people. If people are dissatisfied with the status quo, they’re going to talk about it. Having repeated discussions is just something thats going to happen. Personally, I feel like wasting time discussing things is less of a problem than trying to control what the community talks about. Using phrasing like “relitigation” for example, which I have seen a couple times recently, is problematic in my view. Things will often also have to be discussed multiple times before some good solution is found.

I’m not sure they are fixable in general. We should maybe try to find ways to minimize animosity, and thus deal with the rifts instead of trying to get rid of them.


#43

I’ve come to the conclusion, as a participant in these discussions, that changing the way crates.io works is not on the table realistically. It is my conclusion to work on building an alternative that works as seemlessly as possible that incorporates the ideas that those who want name-spacing and squatting prevention want. I don’t mean that in a negative way like, “forget about crates.io, let’s just take our cookies and go home and build our own”, I mean it positively, like, “OK, if we think this would be better, let’s build it and see how it pans out. If it’s truly a better idea, it will grow, if it isn’t it won’t.”

I hope this isn’t taken as any sort of negative reaction or anything negative against the crates team or any other’s in the community. It isn’t intended as that.


#44

I found this paragraph very interesting:

The rate at which this user uploaded packages eventually resulted in our servers being throttled by GitHub, causing a slowdown in all package uploads or yanks. Endpoints which did not involve updating the index were unaffected.

I was not aware that our servers had been throttled by GitHub, but it makes sense given that a publish can result in multiple git interactions with GitHub and given the rate of a publish roughly every 2 seconds.


#45

Yes, I certainly don’t want to suggest that I’m perfect. It’s also why I haven’t been posting as much, because I am not 100% sure how to do it right.

What I have felt in these discussions is, well, what you say:

If people are going to endlessly discuss things until they get their way, even though there’s nothing new to say, then well, what is there to do?

Different spaces are for different things. The internals forum is supposed to be a place about getting work on the Rust project done. Let’s take this discussion to a different team: what if there was several internals threads, over years, where people said “hey, let’s add GC to Rust.” And the language team says “we’re not interested in adding GC, and we’re also not interested in continuing to discuss this unless something new is brought to the table.” Continuing to discuss the same stuff over and over and over in the team’s space makes the space worse for the team to actually get their jobs done.

This is also not really “controlling” what’s being talked about. If something new is brought to the table, let’s discuss the new information! Furthermore, I’d like to point out that nobody has stopped any discussion either. What has been said is basically “don’t expect the team to respond unless new information is brought up.” There’s only so many hours in the day. I don’t personally think that this is unreasonable.

That’s what I mean by “fix.”


#46

Everyone, a user in this thread asked me to delete their account, and I’ve done so. To those of you joining the discussion now, sorry for it being a bit dis-jointed, but respecting their wishes is important.


#47

Not to belabor it, but, I don’t think someone should be able to say, “I want everything I’ve said publicly purged from the discussion because I no longer want to participate”. That being said, if there are “legal” requirements (maybe GPDR?), then I guess it is what it is.


#48

So basically the behavior was that any requests which touched the index started to shoot up to 10s response times. We don’t know for sure this was due to rate limiting on GitHub, since there’s not much documentation on rate limits for normal git push, but it’s the most likely explanation.


#49

I think it’s more that I feel we should all stay clear of trying to quantifying need or support or anything like that. I know I also have to put in more effort towards that as well. One reason is that implying one side has less support urges people to jump in who don’t really want to. It’s why I jumped in, even though I knew it probably wouldn’t be enjoyable.

Nothing. I think that’s just a fact of life. And people on the “other side” do feel this as well. Remember discussions about how rustfmt shouldn’t be configurable? Or that Ok wrapping pops up again and again. I’ve done that for a couple of topics in the past as well.

The fact that we’re even talking about it being about someone “getting their way” seems problematic. How do you separate people trying to get their way from those venting their frustrations to other community members? In a recent criticism I posted to the subreddit, the first comment said I was making a fuss. How should I even respond to that? We’re moving away from assuming good faith on the other side. I’m sure the core teams have noticed an increase in bad faith assumptions towards them from parts of the community as well.

Namespacing/squatting threads on the subreddit have been locked with the same reasons as well, unless I’m misremembering. And in general I don’t feel like there is such a hard separation in the community in these spaces. Regular disencouragement of something on internals will lead to disencouragement elsewhere.

Maybe a first step would be a change in the approach. The tone seems to me usually like “we’re not interested until there are arguments that convince us”. But the community needs to be able to talk among themselves to find these new arguments, or new value in old ones. How about instead being more encouraging towards moving discussions to the users forum, or the subreddit? Encourage the search for better solutions instead of sending a discouraging message. I’m sure core would love it if people came up with a good solution that makes most people happy, and leaves others at least not too frustrated. I think it would be helpful to signal that more. Communicate that even when the discussions (in the approproate places) don’t work out, core is still happy the community is involved and trying.

To people on the other side, the responses as they currently are can seem dismissive. I think a more positive approach here would also help to funnel things to where they can be discussed, and have a more positive community wide attitude towards those discussions.

So, instead of seeing it as people trying to get their way, we should maybe all try to see it as people caring about issues even after they’ve been shut down a couple times. For example, when Ok wrapping or implicit Ok(()) insertion is brought up once again, I think the proponents would like the opponents (including me) to assume that they care about ergonomics instead of thinking about it as “getting their way”.

One solution I would see, but I don’t think would be liked by the core teams, is to switch from a “one way that fits most” to a “try to find a design that gives solutions to the maximum number of use cases”. I think I brought this up in the past. It just feels like in recent discussions, it’s already clear at the start that one side has to win, and that there can’t be a middle ground.

That is, have less of a streamlined, opinionated approach and more that of a neutral platform. Both with language and ecosystem design. That wouldn’t preclude best practices, idiomatic encouragement, ergonomic defaults and so on.

In the squatting context, that would be trying to find a way for serde to be an easily discoverable top-level project, but winapi not having to reserve every possible Windows library name in advance to maintain consistency. In this specific case, I don’t think anyone even has a good picture of the whole situation and people’s needs yet. It might be fruitful to put together a survey to figure out why people want/don’t want namespaces, what problems they want solved, both from crate publisher and crate consumer standpoint, and then use the survey results as basis for further discussion.

Sorry that this got a bit longer.