On Thu, Feb 02, 2023 at 11:14:33AM +0100, Johannes Schindelin wrote:
quoted
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