Re: [PATCH v7 00/12] Enhance credential helper protocol to include auth headers

> On Thu, Feb 02 2023, Johannes Schindelin wrote:
>
> > On Thu, 26 Jan 2023, Junio C Hamano wrote:
> >
> >> Jeff King <peff@peff.net> 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.