The GMP library's repository is under attack by a single GitHub user

Yes and no. The other side of the argument is that a tarball offers a point in time snapshot of the code that is smaller, and easier to download since there's no need to interact with a complex internet service. Also easier to cache, mirror and back up a single file - major distros appreciate this because we have to mirror sources into build systems and provide sources on demand to satisfy the GPL. There are of course disadvantages to the tarball approach (like, no history, harder to patch) but sometimes the simpler technology can be more robust.

> it's unreasonable and unhelpful to add "seems like your servers just suck"

What is the basis for this quote? Ctrl+F-ing on what look like the relevant pages turns up nothing. Maybe I missed it, but Google seems only to know about 1 instance of phrase from the last week (and it's the one in your comment).

I’m a bit confused as to why 700 automated clone requests per day would be an unreasonable amount of traffic for a project like GMP. That doesn’t sound like much traffic to me, especially since they reportedly have a 24 core CPU with 256GB of RAM. Is cloning a mercurial repo highly server intensive?

Why is this a response to the person you sent this reply to?

BTW, for anyone reading this later, I asked some mercurial folks and putting an http cache in front of clones does indeed work just fine, although using the repo bundles is more performant (but might not be something you could ask folks to do). Given this repo seems fairly low activity (last commit 7 months ago) I doubt there'd be much of a problem with caching reads.

Although given how they are using this repo, they'd probably be better off with a shallow clone, or a subversion proxy, or a snapshot tarball...likely just need a set of files..

Why would you expect a cron task to work differently because a repo is a fork or not? Maybe Actions/Workflows shouldn’t be enabled by default on forks, which used to be the case but that has its problems too. You can disable actions on your forks.

What part isn't mature? The bit where they set limitations for use of their hardware?

So... don't ascribe to incompetence what can easily be explained by malice?

Jesus Christ. "Defensive", "reactive", "immature", "they"? Do people here read management books now?

Granlund is a world class expert and apart from gmp has developed (with Montgomery) and implemented several fast arithmetic algorithms in gcc.

This is standard mailing list talk that always includes a bit of posturing. It predates the joyless, grey, boring, judgemental GitHub hypocrites. You are all so mature!

That's not what I wrote. The lack of competence comes across in e.g.

1. They did not provide enough information for anyone at Microsoft reading the message (probably due to being forwarding it to actually investigate the problem. Like, IP addresses, timestamps, the requested URLs. Hell, they even talk of just "identical requests" rather than identifying them as repository clones. Everything about the message is basically custom made to make investigating it as hard as possible.

2. If the goal was to pressure Microsoft into changing something by rousing up a mob with torches and pitchforks, they should have provided enough information for the actual audience (i.e. the mob) to judge the severity of this "attack". Like, the original complaint was about "thousands" of requests. Over what time period? How long was it sustained? (The logs they pasted in the email thread showed 15 requests over a time period of several minutes.)

3. If the goal was to convince Microsoft to take some action due to some reason other than public pressure, than the aggressive and uninformed communications style (copied by their user community) was not going to do them any favors. If you want people to help you, it helps for them to like you or at least have a neutral opinion. This kind of theatrical posturing might make you feel good, but it's going to actively harm your chances of affecting any change.

4. Reacting by blocking traffic from MS IPs to all ports. Given they weren't under attack, there was no reason to block SMTP and potentially block the main communications channel. Or block the website that contains the message they wanted Microsoft to read. But that's what they chose to do. This appears to actually have been like single-digit qps at most. There really was no reason for a layer 3 firewall to be the first solution to try, but even if it were the chose solution you should be able to target it to just hg with less collateral damage.

5. Running an underprovisioned service (they brag about the big real server hardware they have, but then it turns out the repository serving has access to a single core) and then sticking to it. Increasing capacity to soak the problematic traffic is like step one, and would clearly have been an option here. It moves the incident from an emergency to something that could be managed with less stress. And even if IP blocks turned out to be the chosen long-term solution, having a bit of overprovisioning means that things don't break when it turns out you'd missed an IP.

6. Trying to block IPs one by one. It's a server hosting a code repository for God's sake. Literally the first thing anyone should have thought of is that it's a CI pipeline, or something similar, and that if it was MS address space that it'd be GitHub. And the first search result for "github egress ips" will lead to GitHub's official, up to date, list of egress IPs [0], that they could then have blocked in one batch rather than play whack a mole.

So no, despite your snark I think's it's fair to say there was a clear lack of competence in dealing with a potential abuse issue. Given all those signs and the complete lack of details, why would we believe there analysis of this being an attack or abusive traffic were correct? Because, you know, it wasn't.

(Now, is it reasonable to expect everyone to be competent at this? Of course not. But it is reasonable to not just accept at face value the analysis of somebody who clearly does not have the expertise to do it correctly.)

[0] https://docs.github.com/en/authentication/keeping-your-accou...