Hacker News Reader

Comment by judofyr | Hacker News Reader

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 no official GMP mirror at any of the major code hosting sites (GitHub, GitLab) etc.

View on HN

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.

6.2.1 was released on 2020-11-14, but there's been additional bug fixes, features and speedups since then: https://gmplib.org/repo/gmp/. Not quite sure why they are not cutting a new release when there's been no development in the last 7 months.

> why would you need to download a fresh copy of a dependency that almost never gets updated

The nature of this attack is that 700 forks with each their isolated CI containers is downloading the file oblivious to all the other downloads. If GitHub were to cache this download, they'd have to man-in-the-middle, but people are using curl/wget and not a package manager with caching mirrors.

I'm not even sure cleaning up these 700 DDoS'y forks is that easy.

The idea that you build software from a fixed archive is passé. Everything must be a git clone. Or if they don't use git, you muddle along with hg.

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.

"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.

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.

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.

The idea that not hosting your code on GitHub makes you a “trouble maker” is ridiculous.

Reply on news.ycombinator.com