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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Oct 12, 2021, 21:21 UTC
Message-ID: <YWX8d/VTrkOz5tga@camp.crustytoothpaste.net>
In-Reply-To: <YWXzGeiUSMeq5Key@coredump.intra.peff.net>

On 2021-10-12 at 20:42:01, Jeff King wrote:

Show 24 quoted lines

> On Tue, Oct 12, 2021 at 10:47:01AM -0700, Junio C Hamano wrote:
> 
> > "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 / "-" / "." / "_" / "~"

That's what the schema says.  The text says this:

  A host identified by a registered name is a sequence of characters
  usually intended for lookup within a locally defined host or service
  name registry, though the URI's scheme-specific semantics may require
  that a specific registry (or fixed name table) be used instead.  The
  most common name registry mechanism is the Domain Name System (DNS).
  A registered name intended for lookup in the DNS uses the syntax
  defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123].

Those RFCs disallow the underscore.

If we plan to allow names that are not registered in the DNS, we should clearly specify what those are and document how they work in conjunction with libcurl (which presumably does a DNS lookup on them). It's my guess that there are going to be system resolvers which are not going to accept this syntax in getaddrinfo and as a result, we're going to have various breakage across systems if we try to accept this.

I'm happy to put in a change to reject these hostnames altogether, but I won't get to it before Friday.

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