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

From: Jeff King <peff@peff.net>
Date: Oct 12, 2021, 20:42 UTC
Message-ID: <YWXzGeiUSMeq5Key@coredump.intra.peff.net>
In-Reply-To: <xmqqk0ii3zl6.fsf@gitster.g>

On Tue, Oct 12, 2021 at 10:47:01AM -0700, Junio C Hamano wrote:

Show 15 quoted lines

> "Alex Waite" <alex@waite.eu> writes:
> 
> >   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
> 
> Hmph, given that hostnames cannot have '_' (cf. RFC1123 2.1 "Host
> Names and Numbers", for example), the third URL seems invalid.  Is
> this even a bug?

That may be so for hostnames in general, but URLs seem to allow it. RFC 3986 says:

      host        = IP-literal / IPv4address / reg-name
      reg-name    = *( unreserved / pct-encoded / sub-delims )
      unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"

So underscore is definitely allowed in the host portion. Our code complains during url_normalize(), in this code:

          if (allow_globs)
                  spanned = strspn(url, URL_HOST_CHARS "*");
          else
                  spanned = strspn(url, URL_HOST_CHARS);
  
          if (spanned < colon_ptr - url) {
                  /* Host name has invalid characters */
                  if (out_info) {
                          out_info->url = NULL;
                          out_info->err = _("invalid characters in host name");
                  }
                  strbuf_release(&norm);
                  return NULL;
          }

because earlier we define URL_HOST_CHARS without underscore:

  #define URL_HOST_CHARS URL_ALPHADIGIT ".-[:]" /* IPv6 literals need [:] */

I'm not sure why, given that this otherwise seems to match according to the rfc. This code comes from 3402a8dc48 (config: add helper to normalize and match URLs, 2013-07-31), but there's no mention of underscore there. Possibly it came from earlier rules (rfc1738, for example, has a stricter grammar that allows only alphabit and dashes).

I can't imagine it would cause any problems to allow it here (as noted, we're perfectly happy to use the name in other contexts, and I don't think there any syntactic gotchas here).

Adding "_" to that #define does make it work as expected.

-Peff