I’ve seen other sites for open-source software (small git hosting sites, project web sites, documentation) degrading service because of this problem, and I don’t like to see it.
If I was running such a crawler, I suppose I’d try to at least set up a squid proxy or something that would cache frequent requests. But apparently they don’t care that they are breaking their own source material. I wonder if there is such a technological mitigation that we could use: put a proxy in front of it, both to shield gerrit from excessive traffic and also to block load-intensive endpoints as you say. Why doesn’t blocking them work? It’s a distributed “attack” I suppose? Is it just that gerrit is not efficient enough to serve a high volume of requests, or is the storm so severe that it would overwhelm even a static-file web server? Another way to look at this is if git was commonly served over a peer-to-peer protocol in the first place, we could force crawlers to do their own caching instead of politely answering all these repeated http requests. But it’s still uncommon. For example there are ways of serving up git repos over ipfs, freenet and so on; perhaps something like that could replace anonymous http. On Oct 29, 2026, at 08:40, Jukka Jokiniva via Development <[email protected]> wrote: Dear Qt Developer Community, Over the past several days, codereview.qt-project.org has been heavily targeted by crawler bots, causing periods of degraded performance and, at times, making the service unusable. We have explored various mitigation measures, including blocking load-intensive endpoints, IP-based blocking, and other countermeasures. Unfortunately, these approaches have proven insufficient or too cumbersome to effectively address the problem. As a last resort, I have decided to disable anonymous access to the site. I apologize for any inconvenience this may cause. However, given the impact on the availability and usability of the service, this was the only effective solution available to us at this time. I would like to start a discussion on whether this should become a permanent change. Regards, Jukka Jokiniva, Gerrit Administrator Confidential -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
