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

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 2429 bytes --]

On 2021-10-12 at 21:48:33, brian m. carlson wrote:
> On 2021-10-12 at 21:32:24, Jeff King wrote:
> > On Tue, Oct 12, 2021 at 09:21:59PM +0000, brian m. carlson wrote:
> > > 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.
> 
> There's a well-known bug on Tumblr, where it allocated hostnames for
> users that happened to start or end with a dash, which is not allowed.
> This worked great on Windows systems, which don't care, but every Unix
> system was broken.
> 
> When we decide to allow this particular case, we end up with the problem
> that people won't see consistent behavior across systems and tools.  It
> may be that libgit2 rejects this, or Git LFS, or some other tool in the
> ecosystem, and then we'll have people complaining that "Well, Git
> accepts it, so why don't you?" which I am not eager to see.  I, for
> example, have absolutely zero control over the URL parsing library
> that's used in Git LFS, and the Go team has demonstrated that they don't
> care one bit about supporting Git-related tooling.  That doesn't even
> include a variety of proprietary Unix systems that might have different
> rules or resolvers.
> 
> I am also not eager to see additional bug reports for this case that
> will need to be fixed under the precedent that we accepted a patch to
> fix it before.  If there's a concern that rejecting these hostnames
> altogether would break existing users, then we can just do nothing, and
> tell users that their syntax is not valid and they need to fix their
> hostnames.  This rule has been documented since before ISO standardized
> C, so it shouldn't be new to anyone deploying systems or DNS.

I also just checked, and RFC 5280 specifies the rules for RFC 1123
regarding host names in certificates.  So even if we did accept this, no
publicly trusted CA could issue a certificate for such a domain, because
to do so would be misissuance.  So this at best could help people who
are either using plain HTTP or an internal CA using broken tools,
neither of which I think argue in favor of supporting this.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]