git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>, Alex Waite <alex@waite.eu>,
	git@vger.kernel.org
Subject: Re: [BUG] credential wildcard does not match hostnames containing an underscore
Date: Tue, 12 Oct 2021 21:48:33 +0000	[thread overview]
Message-ID: <YWYCh3+37d27QNjW@camp.crustytoothpaste.net> (raw)
In-Reply-To: <YWX+6OgzN4CDzomO@coredump.intra.peff.net>

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

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.

So I'm fine with doing nothing, or rejecting these hostnames, but not
allowing more lenient syntax, because it will probably be broken
somewhere and we (or someone else in the ecosystem) will have to deal
with it again down the line.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

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

  reply	other threads:[~2021-10-12 21:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-12 14:25 [BUG] credential wildcard does not match hostnames containing an underscore Alex Waite
2021-10-12 17:47 ` Junio C Hamano
2021-10-12 18:00   ` Alex Waite
2021-10-12 18:28     ` Junio C Hamano
2021-10-12 20:45     ` Jeff King
2021-10-12 20:42   ` Jeff King
2021-10-12 20:53     ` Jeff King
2021-10-12 21:12       ` [PATCH] urlmatch: add underscore to URL_HOST_CHARS Jeff King
2021-10-12 21:21     ` [BUG] credential wildcard does not match hostnames containing an underscore brian m. carlson
2021-10-12 21:32       ` Jeff King
2021-10-12 21:48         ` brian m. carlson [this message]
2021-10-12 21:55           ` Jeff King
2021-10-12 21:57           ` brian m. carlson
2021-10-12 22:25             ` Aaron Schrab
2021-10-13 16:21               ` Alex Waite
2021-10-14 11:43                 ` Philip Oakley
2021-10-12 21:12 ` brian m. carlson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YWYCh3+37d27QNjW@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=alex@waite.eu \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).