Live data from Hacker News

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

gmplib.org

31–40 of 91 posts

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

#31
post #28

Earlier quoted context omitted.

It's totally reasonable to say that it isn't malicious and they aren't going to stop it, but it's unreasonable and unhelpful to add "seems like your servers just suck". They also missed or failed to mention that there are 700 forks of the project running the same thing at the same time.

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?

I don't know if it's an unreasonable amount of traffic but it's certainly worth mentioning, 1 repo vs. 700 is a big difference.

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

#32
post #27

Why does forking cause a GitHub actions schedule to run? This is pretty unexpected. I wonder what % of actions builds are useless runs like this? Edit: to the shadowbanned guy who hasn’t realised he’s been shadowbanned for years, that’s not correct.

It's the reason you get random build failure notifications and warning emails that your (free) credits are running out, etc..

Took me a while to figure out what happened the first time I ran into this.

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

#33
post #15

More context: https://github.com/BtbN/FFmpeg-Builds/issues/278 The FFmpeg-Builds repo has a GitHub Actions Workflow which clones the Mercurial repo. However, this runs as a (daily?) cronjob. In addition, this repo has 700 forks and now all of them are running the same workflow. This is out of control for the original author of the repo as there’s no way to change those 700 forks… EDIT: Also relevant is that there’s n…

I'm confused by this statement:

> GMP is at this point the only dependency that does not offer a sane way to clone its repository.

The latest release is from years ago and https://gmplib.org/download/gmp/gmp-6.2.1.tar.lz should contain every file necessary. Why would you need access to the commit history in a build script?

In fact, why would you need to download a fresh copy of a dependency that almost never gets updated from upstream? Surely Github can do some kind of caching.

I wonder what will happen now that their build servers can't even reach the Mercurial repo anymore. I suppose the problem should quickly correct itself soon with all the failing builds.

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

#35
post #15

More context: https://github.com/BtbN/FFmpeg-Builds/issues/278 The FFmpeg-Builds repo has a GitHub Actions Workflow which clones the Mercurial repo. However, this runs as a (daily?) cronjob. In addition, this repo has 700 forks and now all of them are running the same workflow. This is out of control for the original author of the repo as there’s no way to change those 700 forks… EDIT: Also relevant is that there’s n…

So when you fork a project, you automatically also run whatever period actions they have set up periodically as well?

It kinda makes sense, but not in the context of how most people use the "fork" functionality, which to me seems to mostly be a "create a backup of this repo". So GH is building this project 700 times in different forks, for people probably not having made any changes to their fork.

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

#36
post #28

Earlier quoted context omitted.

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?

I'm confused as well. Seems like a negligible amount of traffic at first glance. The administrator mentioned compression, could it really have such a big impact?

Especially if you’re running powerful server-class hardware and great connectivity to the Internet.

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

#37
post #28

Earlier quoted context omitted.

It's totally reasonable to say that it isn't malicious and they aren't going to stop it, but it's unreasonable and unhelpful to add "seems like your servers just suck". They also missed or failed to mention that there are 700 forks of the project running the same thing at the same time.

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?

Those 700 clones would all hit at exactly the same time. That's quite a load for a single server, especially since Mercurial can't be cached that easily.

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

#38
post #27

Why does forking cause a GitHub actions schedule to run? This is pretty unexpected. I wonder what % of actions builds are useless runs like this? Edit: to the shadowbanned guy who hasn’t realised he’s been shadowbanned for years, that’s not correct.

It’s a cron workflow

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

#39
post #15

More context: https://github.com/BtbN/FFmpeg-Builds/issues/278 The FFmpeg-Builds repo has a GitHub Actions Workflow which clones the Mercurial repo. However, this runs as a (daily?) cronjob. In addition, this repo has 700 forks and now all of them are running the same workflow. This is out of control for the original author of the repo as there’s no way to change those 700 forks… EDIT: Also relevant is that there’s n…

I get that the author can't change the forks himself, but his attitude that it's someone else's fault rubs me the wrong way. Blaming GMP for not having a "sane" process and for being a "trouble maker" while taking no responsibility himself. He could easily make an unofficial GMP clone on GitHub, or adjust his CI to not pull as often, and then encourage the forks to pull those changes. But no, it's up to someone else to clean up a mess he caused and conform to his desired workflow.

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

#40
post #15

More context: https://github.com/BtbN/FFmpeg-Builds/issues/278 The FFmpeg-Builds repo has a GitHub Actions Workflow which clones the Mercurial repo. However, this runs as a (daily?) cronjob. In addition, this repo has 700 forks and now all of them are running the same workflow. This is out of control for the original author of the repo as there’s no way to change those 700 forks… EDIT: Also relevant is that there’s n…

So when you fork a project, you automatically also run whatever period actions they have set up periodically as well? It kinda makes sense, but not in the context of how most people use the "fork" functionality, which to me seems to mostly be a "create a backup of this repo". So GH is building this project 700 times in different forks, for people probably not having made any changes to their fork.

[dead]
Post reply on HN