cmd/go/internal/get: isSecure does not parse Git repository URIs correctly

[depp]

go version go1.9.4 darwin/amd64

When Git parses a URL, it checks to see that the : is followed by a //, otherwise it considers the URL to be have [user@]host:path syntax. This is documented in the Git URLs documentation page. However, go get cannot understand the scp-like syntax, this behavior is incorrect.

• See is_url in url.c:19 which shows the correct behavior, called from transport_get at transport.c:828
• See isSecure in vcs.go:56 which shows the incorrect behavior

Here's how to reproduce:

cd $GOPATH/src
mkdir gogetbug
cd gogetbug
git init
git remote add origin git:gogetbug.git
echo $'package main\nfunc main() {}' > main.go
go get -u

The resulting error message is:

package gogetbug: cannot download, git:gogetbug.git uses insecure protocol

This is incorrect, the actual protocol here is SSH and go get is parsing it incorrectly. The workaround is to not have a Git server named git, but isn't that the most sensible name for your Git server?

[fraenkel]

While it uses SSH, it does not provide any encryption (https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols). So does it still qualify as being secure?

[depp]

@fraenkel I am unsure what you mean by "it does not provide any encryption" . SSH provides both authentication and encryption. The only problem here is that the URL is parsed incorrectly... it is parsed as a Git protocol URL, which is incorrect, because it is actually an SSH URL.

[fraenkel]

I see what you mean. You are talking about when there is no scheme. Sorry for the confusion.

[gopherbot]

Change https://golang.org/cl/155077 mentions this issue: cmd/go/internal/get: fix wrong parsing scp url

[rsc]

The go command explicitly avoids attempting to guess what non-URLs mean. Please just use the full URL. Even though this is listed in a section titled "Git URLs" it is plainly not a URL in the sense of RFC 3986.

[depp]

You have a good point that this is not a URL in the sense of RFC 3986, but this is still a bug in go get, because go get is incorrectly claiming that an insecure protocol is being used when in fact this is not true. At a bare minimum, the error message is incorrect.

[depp]

The go command explicitly avoids attempting to guess what non-URLs mean.

There is no need to guess, it's documented.

The term "explicitly" means to me that this is somehow documented behavior of go get, but I was unable to find any documentation for this behavior, and had to figure it out for myself. So if this behavior is intentional, it should at least be documented somewhere.