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:
signature.asc
Description: PGP signature
