Re: [PATCH 2/6] connect: uniformize and group CONNECT_DIAG_URL handling code

From: Junio C Hamano <gitster@pobox.com>
Date: May 2, 2016, 23:14 UTC
Message-ID: <xmqq37q0qcge.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqqfuu0qfo4.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 13 quoted lines

> Torsten Bögershausen <tboegi@web.de> writes:
>
>> git://host:[port]/path/to/repo
>> Knowing that, the "@" will be feed into the name resolver,
>> and that's OK.
>
> Is it OK?  It is plausible that our client side may even want to
> accept git://user:pass@host:port/local/part, and as an anonymous
> service, allow it to go to git://host:port/local/part without
> sending user:pass part over the wire.  Or with the same knowledge
> that git:// is an anonymous service, it is also a plausible policy
> to error such a request out.  To implement either needs a robust
> parsing of the URL, doesn't it?

To put it differently, there is a vast difference between

 (1) knowing that xx@git.kernel.org is asking to access
     git.kernel.org as user 'xx' and failing because of a policy
     that says "we do not send auth material over the wire when we
     know we are doing anonymous access"; and

 (2) not caring the distinction between xx@git.kernel.org and
     git.kernel.org, and implicitly relying on the DNS to forbid '@'
     in the hostname and to return a look-up failure when the whole
     string of the former is taken as a hostname in order to fail
     that request.

If we want to fail the request, we should be in control of the policy to fail. Even in an unlikely (and impossible) world where suddenly resolver starts allowing "xx@git.kernel.org" as a host, we do not want to be making a connection to a bogus host that is not what the end user requested, i.e. git.kernel.org.

Otherwise we cannot change the policy to allow it in the future if it turns out to be necessary.