Junio C Hamano <gitster@xxxxxxxxx> writes:
> Torsten Bögershausen <tboegi@xxxxxx> 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@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxx" 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html