On 2021-10-12 at 14:25:04, Alex Waite wrote:
> 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.

> 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