Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
depp opened this issue Feb 15, 2018 · 7 comments
Closed
Labels
FrozenDueToAge help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@depp
Copy link

depp commented Feb 15, 2018

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?

@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 28, 2018
@ianlancetaylor ianlancetaylor added this to the Go1.11 milestone Mar 28, 2018
@ianlancetaylor ianlancetaylor modified the milestones: Go1.11, Go1.12 Jun 23, 2018
@fraenkel
Copy link
Contributor

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
Copy link
Author

depp commented Jun 23, 2018

@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
Copy link
Contributor

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

@gopherbot
Copy link

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

@rsc
Copy link
Contributor

rsc commented Jan 8, 2019

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.

@rsc rsc closed this as completed Jan 8, 2019
@depp
Copy link
Author

depp commented Jan 8, 2019

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
Copy link
Author

depp commented Jan 8, 2019

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.

@golang golang locked and limited conversation to collaborators Jan 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants