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

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