Hi Ariel, Ariel Machado wrote: > Do we have an alternative download mirror or an ETA for cgit access to be > available again?
First let me answer that question. I don't want to say that the attack has been mitigated. It's still in process. But we do have the CGIT interface online again. It's going to be slower because the attack is still hammering away at it. But it seems sufficiently acceptable with some patience. Hopefully that will continue. And so your CI builds should be back online again now. > Our CI builds rely on Conan recipes that reference the git project to > download source of package dependencies, in this case gnu-config: > https://github.com/conan-io/conan-center-index/blob/master/recipes/gnu-config/all/conandata.yml First let me say that though I sysadmin this system that I did not set this system up. Savannah is a resource that I have been honored to maintain for my time maintaining it. It was here before me. At some point I am hoping it will be here after I have gone. I just have the keys for it for this time. Hopefully others will feel the same that it is a sacred duty to maintain and to leave Savannah in better shape than it was found. I am not saying this following to make an official statement that things must be one way or must be another way. Just that as a practical matter I am trying my best to keep the system running and some kinds of things make it harder and harder. And as such there are things that help and there are things that hinder. Having said all of that if it were me I would never have enabled that feature of cgit of providing tar.gz files of git commit hashes. It's okay for one-off types of human activities. And cgit I am sure was created to improve upon gitweb and to provide a nicer human browsing experience. If it were only humans browsing then it would be fine. But the feature itself exists and therefore people have written in the use of it into automated processes. Once we get automated processes involved that changes the calculus significantly! It can keep up with humans using it but it can't keep up with other machines using it. I think this feature must eventually be removed. I am not in a hurry to remove it. But as use of these types of uses increases it becomes intolerable because it focuses compute effort upon the cgit server and that does not scale. It creates increasing work on the cgit server as all of the many of the herd thunder along building and asking the cgit server to do more and more work for them. It will become increasingly impossible for one centralized server to serve the larger and ever increasing herd of users asking it to do more work. Philosophically I think things must be designed to scale-out where the workload is distributed among the herd of systems building the software. As more systems build the work must be distributed among the machines doing the building. If as more systems build it creates more work on the upstream centralized cgit server than that becomes unsustainable at some point. Instead things must distribute the work. > This recipe attempts to download by getting > "http://git.savannah.gnu.org/cgit/config.git/snapshot/config-191bcb948f7191c36eefe634336f5fc5c0c4c2be.tar.gz"; Fortunately this is a small file bundle and the files in it are relatively small making this one of the more lightweight hits on the system. It's fine. But as this type of process expands to more projects and is used other places then it is heavier on heavier projects. Let's say that this was happening for the Emacs project or another of the heavier ones. Doing an emacs checkout and tar up of a git hash to distribute such a tar file then becomes a heavy workload upon the server. The way I have set up CI/CD servers in the past always includes a local mirror of all remote git repositories. Then the CI/CD servers pull from the local mirror to the build systems. That way the CI/CD had a reliable LAN path to the local mirror and everything is self-contained at that point. That way the git mirroring could fail due to Internet glitches and upstream glitches and the local CI/CD build was unaffected by it. The mirror can be updated upon upstream commit event by notification. That way as soon as a push event happens upstream the downstream mirrors can pull the change and then kick off an automated build. Personally I have used email but Corwin uses a UDP notification which is fancier and very light weight. Bob
