Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

gmplib.org

Post reply on HN
Print view View original

21–30 of 91 posts

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

#21

Post by burkaman »

CtrlAltDelete51 wrote: post #16
progval wrote: post #10

Initial email mentioning it on GMP's mailing list: https://gmplib.org/list-archives/gmp-discuss/2023-June/00690... Reply from Github: https://gmplib.org/list-archives/gmp-devel/2023-June/006162....

That seems like a perfectly reasonable response. They even provided the project so GMP could reach out.

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.

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

#22

Post by maxmcd »

I thought people sometimes used forks just like another form of star. Save the repo for later review. I have so rarely seen any commits or changes when someone forks my public github repos.

It's weird to think about github actions crons in the context of this pattern. A casual "I'll mark this to check out later" could result in lots of billable computation.

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

#23

Post by tremon »

judofyr wrote: 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…

[flagged]

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

#24

Post by [deleted] »

judofyr wrote: 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…

[deleted]

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

#26

Post by teraflop »

runeks wrote: post #19

Sounds like GitHub actions should be caching clones of foreign Git repos. People already trust GH CI enough to run their code, so why not trust their cache as well?

In this case, it's a foreign Mercurial repository, not Git.

And remember that users' builds can contain arbitrary custom shell scripts that perform "git clone" or "hg clone" commands. It could be very, very difficult for Github to build an automated system that meddles with the behavior of those scripts to introduce caching, while guaranteeing not to break anything.

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

#28

Post by 542458 »

burkaman wrote: post #21
CtrlAltDelete51 wrote: post #16

Earlier quoted context omitted.

That seems like a perfectly reasonable response. They even provided the project so GMP could reach out.

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?

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

#29

Post by folkrav »

aseipp wrote: post #18

The repository in question, based on the email from Mike Blacker, sent to gmp-devel[1]: https://github.com/BtbN/FFmpeg-Builds There's a bunch of build variants here, for various platforms, in different ways. Classic "you have to create the cartesian product of all variables" approach. Here is the single build matrix for a single "Build FFMPeg" job: https://github.com/BtbN/FFmpeg-Builds/actions/runs/530351117... You c…

> It already is cached by the docker image. The problem why it's SO MANY requests is because hundreds of people have forked this repository, and now at the same time (due to the workflow cron) start an image build. 99% of the days, it'll just use the cached image and not cause any network requests whatsoever.

> If it builds new images, it'll be at max 10 requests to fetch the latest snapshot in parallel from my end (that's how many parallel jobs Github allows for free), which shouldn't be an issue. I've already switched GMP back to use an outdated release tarball because of how annoyingly flakey their mercurial server is.

Straight from the repo author. Looking at the workflow, not sure how it could really fetch less than it already does.

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

#30

Post by matheusmoreira »

542458 wrote: post #28
burkaman wrote: post #21

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'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?
Post reply on HN