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

From: Jeff King <peff@peff.net>
Date: Oct 12, 2021, 21:32 UTC
Message-ID: <YWX+6OgzN4CDzomO@coredump.intra.peff.net>
In-Reply-To: <YWX8d/VTrkOz5tga@camp.crustytoothpaste.net>

On Tue, Oct 12, 2021 at 09:21:59PM +0000, brian m. carlson wrote:

Show 18 quoted lines

> > 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.

Thanks, I skimmed looking for some resolution to this mismatch, but didn't find that paragraph.

Show 6 quoted lines

> 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 don't think this makes anything worse. Either the underscore works or it doesn't for general use on your system. This just means we'll allow http.<url>.* config for it.

And it does indeed work fine on my system, via DNS. My stub resolver is glibc, and curl itself is fine with it. The server side answering the query was djbdns (tinydns, with dnscache as a recursive resolver in between). I could believe that other implementations may be more strict, though.

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

IMHO _that_ is the thing that will produce breakage. People who are not using URL-specific config but are happily using foo_bar.example.com will now get a failure for something that used to work.

-Peff