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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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

> 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux