From: "brian m. carlson" <email@example.com> To: Drew DeVault <firstname.lastname@example.org> Cc: Eli Schwartz <email@example.com>, Jonathan Nieder <firstname.lastname@example.org>, email@example.com Subject: Re: Regarding the depreciation of ssh+git/git+ssh protocols Date: Wed, 17 Mar 2021 22:06:44 +0000 [thread overview] Message-ID: <YFJ9dI96TO5IdGRZ@camp.crustytoothpaste.net> (raw) In-Reply-To: <C9YUBUYH7PWU.3PHDZR2YCUEOX@taiga> [-- Attachment #1: Type: text/plain, Size: 4184 bytes --] On 2021-03-16 at 14:21:13, Drew DeVault wrote: > On Tue Mar 16, 2021 at 7:54 AM EDT, brian m. carlson wrote: > > So I'm very much opposed to adding, expanding, or giving any sort of > > official blessing to this syntax, especially when there are perfectly > > valid and equivalent schemes that are already blessed and registered > > with IANA. > > This convention is blessed by the IANA, given that they have > accepted protocol registrations which use this convention: > > https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml I assume that you're volunteering to write the RFC to register these with IANA? If not, then they are indeed non-standard and will remain so. I should point out that I don't believe the IANA will accept such a registration, because they will believe it to be duplicative of the existing scheme. But if you want to go this route, we should only proceed if we register them with IANA. > > It's difficult enough to handle parsing of SSH specifications and > > distinguish them uniformly from Windows paths (think of an alias named > > "c"), so I'd prefer we didn't add additional complexity to handle this > > case. > > There's no additional complexity here: git remotes are URIs, and any > implementation which parses them as such already deals with this case > correctly. Any implementation which doesn't may face all kinds of > problems as a consequence: SSH without a user specified, HTTPS with > Basic auth in the URI username/password fields (or just the password, > which is also allowed), and so on. Any sane and correct implementation > is pulling in a URI parser here, and if not, I don't think it's fair for > git to constrain itself in order to work around some other project's > bugs. We accept local paths in a variety of situations and SSH specifications, neither of which are URLs. The ultimate problem is that we support Windows paths and need to handle them correctly on Windows but don't support them on other operating systems and need to not handle them there. So, somehow, in portable code which does not vary based on operating system, we need to decide what should be a local path and what should be an SSH specification and do that in a way compatible with Git. Git LFS has also run into the problem that the URL parser we use has gotten stricter in a point release due to CVEs against it which broke various kinds of parsing of our SSH URLs that were previously accepted. This almost certainly bit other Go-based tools that work with Git repositories as well, since everyone uses the standard library URI parser. If we only supported valid URLs, this would be much, much easier. That is not at all the case, and it has never been the case for Git. > > Lest you think that only Git has to handle parsing these > > I don't, given that my argument stems from making it easier for > third-party applications to deal with git URIs :) This does not make my life as a maintainer of said third-party application easier. It complicates it significantly, because people often upgrade Git without upgrading Git LFS and then are unhappy when the five-year old version they use from their distro doesn't support every new feature. Adding this feature which duplicates existing functionality does not improve my life as a user of Git, as a developer of Git, as a maintainer of a number of third-party tools which interact with Git, or as someone who maintains part of a hosting platform. It also will inevitably confuse users who will want to know the relevant difference between the URLs and which they should use. They will then see the new type of URL and wonder why it does not work with the version they are using. And many users already don't understand the difference between HTTPS and SSH URLs, which is compounded by the fact that many Windows users have never before and will never otherwise use SSH. In case it was not already clear, I'm very strongly opposed to this proposal. It seems to make a lot of needless work without a clear and convincing benefit. -- brian m. carlson (he/him or they/them) Houston, Texas, US [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2021-03-17 22:07 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-15 16:27 Drew DeVault 2021-03-15 17:56 ` Jonathan Nieder 2021-03-15 18:14 ` Drew DeVault 2021-03-15 22:01 ` brian m. carlson 2021-03-16 0:52 ` Drew DeVault 2021-03-16 1:02 ` Jonathan Nieder 2021-03-16 1:05 ` Drew DeVault 2021-03-16 21:23 ` Jeff King 2021-03-17 14:49 ` Drew DeVault 2021-03-18 21:30 ` Junio C Hamano 2021-03-18 21:53 ` Drew DeVault 2021-03-16 4:38 ` Eli Schwartz 2021-03-16 11:54 ` brian m. carlson 2021-03-16 14:21 ` Drew DeVault 2021-03-16 21:28 ` Jeff King 2021-03-17 14:50 ` Drew DeVault 2021-03-17 0:45 ` Jakub Narębski 2021-03-17 14:53 ` Drew DeVault 2021-03-17 22:06 ` brian m. carlson [this message] 2021-03-18 12:53 ` Drew DeVault 2021-03-16 18:03 ` Eli Schwartz 2021-03-17 22:15 ` Jonathan Nieder 2021-03-31 4:23 ` Eli Schwartz 2021-04-07 13:46 ` Mark Lodato 2021-04-07 19:46 ` Junio C Hamano 2021-04-13 8:52 ` Kerry, Richard 2021-03-16 0:54 ` Drew DeVault
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=YFJ9dI96TO5IdGRZ@camp.crustytoothpaste.net \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Regarding the depreciation of ssh+git/git+ssh protocols' \ /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
Code repositories for project(s) associated with this 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).