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
Attachment:
signature.asc
Description: PGP signature
