Re: [BUG] credential wildcard does not match hostnames containing an underscore

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Oct 12, 2021, 21:12 UTC
Message-ID: <YWX6PJrjgp6rHZu/@camp.crustytoothpaste.net>
In-Reply-To: <28ff3572-1819-4e27-a46d-358eddd46e45@www.fastmail.com>

On 2021-10-12 at 14:25:04, Alex Waite wrote:

Show 22 quoted lines

> What did you do before the bug happened? (Steps to reproduce your issue)
> 
>   I configured my ~/.gitconfig so that git credentials invoke a helper for a
>   subdomain using wildcards. For example:
> 
>   [credential "https://*.example.com"]
>           helper = "/usr/local/bin/custom_helper"
> 
>   This works for all tested subdomains /except/ for those which contain an
>   underscore.
> 
>   authenticates without prompting:
>     git clone https://testA.example.com
>     git clone https://test-b.example.com
> 
>   prompts for authentication:
>     git clone https://test_c.example.com
> 
> 
> What did you expect to happen? (Expected behavior)
> 
>   I expected the pattern matching to work for all resolved URLs.

As mentioned below and elsewhere in this thread, this isn't a valid hostname, and as a result, this isn't even a valid URL according to RFC 3986 unless you intended it to be resolved in a system other than DNS.

I don't personally see a reason to accept locally specified hostnames (e.g., in a hosts file) which don't conform to RFC 1123 or which otherwise don't conform to the DNS standards for hostnames, but perhaps others can see a good reason to do so.

Show 21 quoted lines

> Anything else you want to add:
> 
>   If I don't use pattern matching, and instead state the URL explicitly in
>   ~/.gitconfig, it works as expected. For example, the following works:
> 
>   [credential "https://test_c.example.com"]
>           helper = "/usr/local/bin/custom_helper"
> 
>   As part of writing this bug report, I learned that underscores are not valid
>   DNS characters for hostnames (but are valid for other record types, which are
>   largely irrelevant to git).
> 
>   What is notable is that git pattern matching enforces the spec more strictly
>   than without pattern matching (and more strictly than the OS and every DNS
>   server between my system and the authoritative DNS server).
> 
>   At minimum, git should be consistent with itself.
> 
>   As for which behavior is "correct", the question is whether git wishes to
>   follow/enforce the spec tightly, or not get in the way of a real-world oddity
>   that everything else seems to tolerate.

There are a variety of systems which won't accept such a hostname, so I think at best we should reject such hostnames altogether and prevent this from working at all, since they are likely to be subtly broken in a variety of ways and we won't want to try to fix all of the cases in which things are broken. To me, this appears to be simply a case where we should improve error handling.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA