Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/go: go get -u behaves as if -f is always provided (for non-custom import paths) #20039
This is an issue since 2015. I discovered it on January 11, 2017, but I'm only getting around to reporting it now. I have a suggestion for resolution.
However, for packages with a non-custom import path (custom import path being one that is defined by HTML meta tags, see
For custom import paths (e.g.,
What version of Go are you using (
Go 1.4 added import path repo URL checking in addition to the import path comment. It was very strict, performing a simple URL string equality check.
Issue #10952 was opened. It quoted a forwarded message from golang-dev mailing list that described the original problem:
Later, #10952 was reopened as #16471, that suggested that the fix in CL 10693 was not optimal, and suggested a better fix. This new issue #16471 was then closed by CL 31658, which changed the behavior so that the remote URL check applied only to custom import paths.
This issue is essentially a reopen of both those issues. I think I have a suggested fix for the original problem that was reported in #10952. Let me explain the problem as I understand it.
Let's consider GitHub repos, since this is where the issue comes up most often.
GitHub supports cloning repos via HTTPS and SSH. The latter can be expressed as a normal URL (
A weird/unfortunate thing about GitHub repos is that the remote URL they're cloned from can have an optional ".git" suffix. In other words, these two remote URLs are equivalent:
When visiting https://github.com/user/repo in your browser, GitHub's UI usually displays clone URLs with the optional ".git" suffix:
Next, some people prefer to use SSH URLs instead of HTTPS for cloning their git repositories for various reasons. This is what the original post in https://groups.google.com/forum/#!topic/golang-nuts/Zi-Kw2tbif8/discussion was asking about.
The change in CL 10693 effectively allowed using SSH URLs instead of HTTPS, by making remote URL checking apply only to packages with an import path comment (at the time). Later, it got changed in CL 31658 to apply to custom import paths only.
I think we should allow SSH URLs, but I believe there is a better way to do it without completely removing the remote URL check for non-custom import paths.
I think we should fix this issue, as well as the original issue from #10952, by applying the remote URL check to all repositories, but:
I'm happy to work on a CL if this gets approval.
I agree with pretty much everything you've described here. 1 and 3 seem like net wins.
As far as 2:
What about always ignoring
I'm simply trying to keep the rules simpler and not dependant on hard-coding
That is an option, but it seems worse than ignoring ".git" suffixes for "github.com/xxx/yyy" URLs only.
I'd prefer to do things correctly. And this issue is about fixing the lax.
The simplest solution is not to do anything special regarding ".git" suffixes.
When fetching new packages using
I know that GitHub does not allow the repository name to end with ".git" at this time, so it's relatively safe to treat ".git" suffix as harmless for "github.com/xxx/yyy" URLs:
However, if you also ignore ".git" suffix for non-github.com URLs, that means it will apply to other VCSes, including Bazaar, Mercurial, and Subversion. It's possible some code host will not have such rule, so
If you still want not to verify that each package has been checked out from the source control repository implied by its import path, the
There shouldn't be any issues with doing
I agree with you then - especially given how
I still think this could cause people reporting bugs like "
Now that that Go 1.10 tree is open, I'd like to begin working on this, if this gets approval. It's better to get this done sooner in the cycle rather than later, so that the fix can be evaluated and adjusted as neccessary before feature freeze.
Here's what I need to know to proceed:
Thanks for taking a look.
I take it you mean that this would negatively affect people who try to use a github fork as a remote, without changing the import path of the original package, right?
I was going to say that "I realize that security and convenience are often at odds with each other, but shouldn't we prioritize security over convenience anyway?", but after thinking more, I think it's important to consider the threat level and amount of inconvenience caused. In this case, I agree that the threat level is low, so I'm okay with waiting.
One of the reason I'm not worried about doing
If/when you think it's a better time to revisit this, please let me know, I might want to work on it.
OK, sounds good. Once we have a decent package management story I think that will probably eliminate "automatic checkouts from version control systems" as a distribution mechanism, and with it many of these problems. (Of course we will retain the ability to work from checkouts if you do them yourself, but the more we get into problems with the subtleties here the more clear it is that version control systems are too complex to be the general default mechanism.)