On Thu, Feb 02, 2023 at 11:14:33AM +0100, Johannes Schindelin wrote: > > I do not mind reverting the merge to 'next' to have an improved > > version. Your "do we really want to add a custom server based on > > questionable codebase whose quality as a test-bed for real world > > usage is dubious?" is a valid concern. > > Except. > > Except that this code base would have made for a fine base to potentially > implement an HTTPS-based replacement for the aging and insecure > git-daemon. I'm skeptical that it is a good idea for Git to implement a custom http server from scratch. There are a lot of extended features people would want in a production-ready server. TLS, HTTP/2, and so on. The code under discussion is pretty stripped-down. A network service is also a pretty big attack surface for buffer overflows, etc. It feels to me like the resources required to make it good enough for normal users to run would be substantial. And we'd be better off trying to integrate with an existing project that provides a web server (whether it's a lightweight server that supports us as a CGI, or a library that does most of the heavy lifting). > That code base (which is hardly as questionable codebase as you make it > sound because it has been in use for years in a slightly different form) Perhaps I'm being too hard on git-daemon. But my operational experience with it is that it has several flaws, mostly around the child-management code. We rewrote that code totally to make it usable at GitHub. As a concrete example, the parent daemon process will do a linear walk over all children, calling waitpid() on each one. This makes handling N children quadratic, and the daemon grinds to a halt when there are many clients. > In addition, it causes a loss of test coverage because Apache is not > available in all the setups where the "questionable" code would have had > no problem being built and validating the credential code. > > Windows, for example, will now go completely uncovered in CI regarding the > new code. I'm sympathetic there, though it's a problem for all of the existing http code, too. Is there some server option that would be easier to run everywhere, but that doesn't involve us writing a server from scratch? Certainly I have no particular love for apache or its configuration language. -Peff
