11–20 of 91 posts
From their website: "NEWS 2023-06-16: The GMP server is under attack by several hundred IP addresses owned by Microsoft cooperation. We do not know if this is made with malice, if it is some sort of mistake, or if some of their cloud customer is running the attack. The attack targets the GMP repo, with thousands of identical requests, most of which makes our server compress the data. We're firewalling off all of Micr…
From their website: "NEWS 2023-06-16: The GMP server is under attack by several hundred IP addresses owned by Microsoft cooperation. We do not know if this is made with malice, if it is some sort of mistake, or if some of their cloud customer is running the attack. The attack targets the GMP repo, with thousands of identical requests, most of which makes our server compress the data. We're firewalling off all of Micr…
Link?
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.
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....
So another classic case of someone's constant integration system DoS'ing an open source project. We've all become so blinded by big tech and how they operate we fail to see how our actions can affect smaller projects we depend on CI providers really should do more to prevent and mitigate these when they happen. They should have outbound firewalls, and the ability to request a rate limit on IPs. Having to resort to a…
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/991#not...
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 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/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....
People already trust GH CI enough to run their code, so why not trust their cache as well?
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.