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

61–70 of 91 posts

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

#61

Post by beardog »

maxmcd wrote: post #22

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.

Disabling jobs for new forks until a commit is made in the fork or an option is toggled on the settings page would be a fix, although maybe i'm missing something.

I often had experiences where people would fork my repos and I would get hopeful that someone might contribute, but it turns out that they just treat forking as bookmarking.

Github running actions for forks wrongly assumes that users use the fork feature for its original purpose.

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

#62

Post by 542458 »

jasonjayr wrote: post #55
542458 wrote: 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?

It's 700 automated clone requests at the same moment due to inheriting a cronjob.

Sure, but even if each clone tied up an entire core of their Epyc 7402P for 5 seconds (which seems pessimistic to me) the entire traffic spike would be over in 2.5 minutes.

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

#63

Post by eddythompson80 »

orf wrote: post #57
eddythompson80 wrote: post #48

Earlier quoted context omitted.

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.

Why would I expect pressing the fork button would suddenly enable redundant and, in aggregare, expensive cronjobs? Most people fork to make a pull request and then never delete the fork after. Why are any scheduled actions required for that?

It depends on how you use the fork and what you use it for. That’s up to the project to decide, not GitHub. Most workflows are triggered on an update-event, like git push or create a tag or branch or pull request etc. You want them to trigger on your fork separately from the main repo because (a) the secrets aren’t shared between forks and main repo (b) you want to catch linters, automated tests, build issues and all the other things workflows are used for before you create a pull request if possible.

Cron tasks are the odd exception. You can use them to update dependencies in your repo, or track an external dependency and rebuild your stuff with it, or nightly integration tests with external APIs, etc.

Maybe they could enable all actions but cron actions, but then that’s just as equally confusing. I’d rather GitHub stay out of deciding what’s “expensive” and what’s not. Either enable all actions on forks by default, or disable them by default. They decided to enable them by default and give each user however many minutes of free actions time. I’m sure there is a better upsell opportunity there too.

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

#64

Post by xyse53 »

jsnell wrote: post #9
retrocryptid wrote: post #3

Microsoft employee is dismissive of world outside Microsoft. Film at 11. Which is to say... what's MSFT's motivation to worry about this?

They've clearly worried enough about it to have somebody investigate the initial report and rootcause it. (And the motivation for that wasn't just some kind of a huge public outcry on the first report, because as far as I can tell that sank without a trace at least on HN). If the traffic from that customer is within the typical norms of git usage, rather than clearly abusive, then what further action would you expect…

Initially, I wanted to reply to you and say it's unfair to judge the person as incompetent; I still think it's a bit unfair because they develop a specialized library and their choice of hosting shouldn't need to be modernized at every step.

However, reading through their response thread [0] I do think they aren't appearing particularly mature. It feels like they are refusing to characterize what is actually going on and digging in and escalating this defensive mindset.

[0] https://gmplib.org/list-archives/gmp-devel/2023-June/thread....

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

#65

Post by rhdunn »

IIUC, you can add "on" triggers to the GitHub Actions to only build on the original repository. That would prevent this issue. Making the change in this repository would require having the forks updated, so maybe the owner can then reach out to the owners of the forks asking them to update.

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

#66

Post by plorkyeran »

jeroenhd wrote: post #33
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…

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 upd…

"I've already switched GMP back to use an outdated release tarball"

It needed the commit history specifically because the latest release is from years ago.

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

#67

Post by retrocryptid »

xyse53 wrote: post #64
jsnell wrote: post #9

Earlier quoted context omitted.

They've clearly worried enough about it to have somebody investigate the initial report and rootcause it. (And the motivation for that wasn't just some kind of a huge public outcry on the first report, because as far as I can tell that sank without a trace at least on HN). If the traffic from that customer is within the typical norms of git usage, rather than clearly abusive, then what further action would you expect…

Initially, I wanted to reply to you and say it's unfair to judge the person as incompetent; I still think it's a bit unfair because they develop a specialized library and their choice of hosting shouldn't need to be modernized at every step. However, reading through their response thread [0] I do think they aren't appearing particularly mature . It feels like they are refusing to characterize what is actually going o…

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

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

#68

Post by retrocryptid »

jsnell wrote: post #9
retrocryptid wrote: post #3

Microsoft employee is dismissive of world outside Microsoft. Film at 11. Which is to say... what's MSFT's motivation to worry about this?

They've clearly worried enough about it to have somebody investigate the initial report and rootcause it. (And the motivation for that wasn't just some kind of a huge public outcry on the first report, because as far as I can tell that sank without a trace at least on HN). If the traffic from that customer is within the typical norms of git usage, rather than clearly abusive, then what further action would you expect…

Yes. Repeated duplicate requests from MSFT ips are very clearly caused by gmp's server misconfiguration.

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

#69

Post by retrocryptid »

xyse53 wrote: post #64
jsnell wrote: post #9

Earlier quoted context omitted.

They've clearly worried enough about it to have somebody investigate the initial report and rootcause it. (And the motivation for that wasn't just some kind of a huge public outcry on the first report, because as far as I can tell that sank without a trace at least on HN). If the traffic from that customer is within the typical norms of git usage, rather than clearly abusive, then what further action would you expect…

Initially, I wanted to reply to you and say it's unfair to judge the person as incompetent; I still think it's a bit unfair because they develop a specialized library and their choice of hosting shouldn't need to be modernized at every step. However, reading through their response thread [0] I do think they aren't appearing particularly mature . It feels like they are refusing to characterize what is actually going o…

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

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

#70

Post by orf »

eddythompson80 wrote: post #63
orf wrote: post #57

Earlier quoted context omitted.

Why would I expect pressing the fork button would suddenly enable redundant and, in aggregare, expensive cronjobs? Most people fork to make a pull request and then never delete the fork after. Why are any scheduled actions required for that?

It depends on how you use the fork and what you use it for. That’s up to the project to decide, not GitHub. Most workflows are triggered on an update-event, like git push or create a tag or branch or pull request etc. You want them to trigger on your fork separately from the main repo because (a) the secrets aren’t shared between forks and main repo (b) you want to catch linters, automated tests, build issues and all…

Would you say the percentage of total forked repos that benefit from (or are even aware of) scheduled actions is less or more than 0.001%?
Post reply on HN