On Thu, Feb 02 2023, Johannes Schindelin wrote: > Hi Ævar, > > On Thu, 2 Feb 2023, Ævar Arnfjörð Bjarmason wrote: > >> On Thu, Feb 02 2023, Johannes Schindelin wrote: >> >> > On Thu, 26 Jan 2023, Junio C Hamano wrote: >> > >> >> Jeff King <peff@xxxxxxxx> writes: >> >> >> >> >> Thanks, both. Let's merge it down. >> >> > >> >> > Sorry, I'm a bit late to the party, but I left some comments just now >> >> > (this topic had been on my review backlog for ages, but I never quite >> >> > got to it). >> >> > >> >> > Many of my comments were small bits that could be fixed on top (tiny >> >> > leaks, etc). But some of my comments were of the form "no, do it totally >> >> > differently". It may simply be too late for those ones, but let's see if >> >> > Matthew finds anything compelling in them. >> >> >> >> 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. >> > >> > 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) >> > would have had the opportunity to mature in a relatively safe environment: >> > our test suite. And eventually, once robust enough, it could have been >> > extended to allow for easy and painless yet secure ad-hoc serving of Git >> > repositories, addressing the security concerns around git-daemon. >> > >> > And now that we're throwing out that code we don't have that opportunity, >> > making the goal to deprecate the git-daemon and replace it by something >> > that is as easy to set up but talks HTTPS instead much, much harder to >> > reach. >> >> There's many reasons for why you almost never see a git:// URL in the >> wild anymore. > > I am unwilling to accept that statement without any source to back it up. > Thin air is no substitute for reliable evidence. Most people exposing git over the Internet use the ssh or http transport, and our own "git" protocol is relatively obscure. If you need data I think major hosting sites not offering it, or deprecating it, is a pretty strong signal, e.g. Microsoft with: https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git But if you'll grant me that it's 50/50 git/other protocols (I think it's a *lot* more lopsided), then clearly combining git with 3rd party server components isn't the limiting factor on deploying it. Which is the point I was going for. >> But if "easy and painless" was synonymous with "built with git" or >> "ships with git" as you seem to be using it, surely it would be more >> common than doing the same with http or https, which requires an >> external server? > > Oh whoa... "requires an external server"? > > My entire point was to suggest a way forward for an _internal_ server that > speaks https:// instead of git://. I understand that. > So I am not suggesting what you seem to have understood me to suggest. I wasn't suggesting that, and you seem to have not read my reply to the end, which should have addressed that. Briefly, we'd like to be guaranteed to have regcomp() and regexec(), but did the Git project write its own regex engine? No, we imported (with some minor tweaks) one from glibc/gawk (whatever current issues have cropped up with it lately...). So can't we do the same for a httpd? If it really comes to "we must have it in-tree"? It seems to me that there's a continuum here, which is at the very least: 1) We require an external package (e.g. ssh, or apache/httpd) 2) We require an external package *or* built-in (e.g. our SHA-1 implementations) 3) We use an external package as-is (sha1dc) 4) We adapt an external codebase, and perma-fork it (git-imap-send, although that example also kind of sucks) 5) We write it "in-house" from scratch. It seems to me from reading the upthread that we're jumping straight from #1 to #5, and it's not clear to me why that is. Not even that, we currently have CI tests running Apache on *nix boxes, but you're suggesting a loss of coverage on Windows Is it really harder to just install (or even ship our own package of) Apache for Windows than it is to embark on PID file handling, logging, timeout management and the long tail of "80% is easy, the rest is really hard" of writing our own production-class httpd (as the suggestion is to have it eventually mature beyond the test suite)? Maybe, all I'm saying (in trying to mediate the discussion between you and Jeff) is that it's not obvious to me why that is...
