Re: Regarding the depreciation of ssh+git/git+ssh protocols

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

[-- 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 --]