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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> 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://.

So I am not suggesting what you seem to have understood me to suggest.

Ciao,
Johannes

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux