3 ms·
The repository in question, based on the email from Mike Blacker, sent to gmp-devel[1]: https://github.com/BtbN/FFmpeg-Builds https://github.com/BtbN/FFmpeg-Bu
by aseipp 3y ago
The repository in question, based on the email from Mike Blacker, sent to gmp-devel[1]:
https://github.com/BtbN/FFmpeg-Builds 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/5303511170 https://github.com/BtbN/FFmpeg-Builds/actions/runs/530351117...
You can look through the code and see that each of these will trigger a download.
The developer also added an interesting commit today, stopping forks from having the CI work instantly. Why? Because by default they would all share the same cron entry, and therefore launch all at the same time every night. So now new forks will need to go in and tweak/spread the Cron timer around if they want builds of their own
https://github.com/BtbN/FFmpeg-Builds/commit/78191a73a6a1959d13a62a4d6adb9ddeffa18522 https://github.com/BtbN/FFmpeg-Builds/commit/78191a73a6a1959...
But there are already over 700 forks of this repository, so the current path is unsustainable.
So in short:
- This isn't an "attack", and it's unclear of the direct volume, but anyway, it doesn't matter because ultimately gmplib.org had strain caused by it.
- GitHub correctly identified the responsible user when asked, and it did not in any way seem malicious, but certainly excessive.
- The build/CI infrastructure for this project definitely hammers the project more than it probably should, exact specifics aside.
- The owner of the project put in place a small (future) mitigation for future forks, but for now IP banlists will probably remain, I'd guess?
- Please try to cache things more aggressively in your build jobs.
[1] https://gmplib.org/list-archives/gmp-devel/2023-June/006162.html https://gmplib.org/list-archives/gmp-devel/2023-June/006162....
- folkrav 3y ago> 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.
- aseipp 3y agoInteresting, I didn't look far back enough. And I didn't realize it cloned from Mercurial first instead of using the tarball either; that'll hurt a lot more, too!
- miyuru 3y agoSome more information here. The GitHub user has already removed repo from the code and uses a tarball now. https://github.com/BtbN/FFmpeg-Builds/commit/d75466340a9a5985e546fff9756b976727c4ab98 https://github.com/BtbN/FFmpeg-Builds/commit/d75466340a9a598...