Pre-RFC: crate creator rate limiting in

So, you need a GitHub account to authenticate with, but you don't need to actually publish the source code on GitHub (or any git repository). Still, the team has the tools needed to handle such cases.

It's probably best to hop into the #docs-rs channel on Discord to chat about this, as most of the team doesn't frequently check internals.

1 Like

All accounts go back to GitHub right now. Sure, I can give an API token of my account to someone without their own, but then that's me putting my account on the line at that point. And the linked post mentions that the code doesn't need to live on GitHub, not that one doesn't need a GitHub account.

Thank you to both of you for explaining this to me, I clearly misunderstood what @kornel was saying. In that case, @mathstuf is right, and working with the GitHub abuse team would work.

OK, so if I understand everything that's been said thus far correctly, a) this hasn't been a really big issue in the past, b) it's not expected to be a major issue in the future (this was a one-off issue), and c) the docs team already has a way of dealing with the issue that works well enough for the moment, and this is just one that got away from everyone. Is this all correct?

If so, it sounds like reworking the entire pipeline would involve a lot of work for very little gain. Maybe the outcome of this Pre-RFC chat should be an RFC that outlines what possible courses of action could be taken in the future, if the need arises. That way we'll have a battle plan that can be dusted off, freshened up, and put in place with less effort than trying to invent something on the spot if/when abuse becomes a serious issue. Would that work for everyone?

1 Like

This topic seems related to the Adios Pagers article in TWiR. I was personally surprised to hear team members were rotating pager duty, and it sounds like this is a rare care where the larger user community was affected, but I get the impression the team is already working hard on it.


Speaking with my hat, and having dealt with abuse situations like this in the past, I'm wary having an RFC specifying what the team has to do in case of abuse. We can't foresee any possible abuse that could happen and what the best way to address it is, and tying the team's hands in those cases would likely worsen the situation, not improve it.

By the way, the team is completely separate from the team (the only membership overlap is me, as I'm in both teams), both in a decision-making and in an operational point of view. There isn't anyone on pagerduty for at the moment.


NONONONONONO!!! I'm sorry if I gave the impression that the RFC would be prescriptive, I meant that the RFC would be a collection of ideas that have already been thought through that the docs teams could then reference if/when abuse picks up, kind of like having a strategy guide or a tactics manual available. The idea is that the RFC would outline possible courses of action that can be taken, their perceived advantages and disadvantages, and maybe when/how to apply them quickly. That way, if abuse suddenly picks up, you don't have to try to invent something while under attack, you can quickly browse a set of ideas, pick things that you think might work, and adapt them to the current situation. If none of the tactics would work, then at least you don't have to spend time trying them when their disadvantages show that they won't work in the given situation.

1 Like

I posted this in the other thread, but in case people aren't looking at the other thread:

1 Like

3 posts were merged into an existing topic: build prioritization