go get on private gitlab repository fails with "no secure protocol found for repository" msg #71389
Comments
gabyhelp
added
the
BugReport
|
gitlab works without the .git suffixes (example https://gitlab.com/gitlab-org/gitlab/-/issues/29629). if you have problems, it's because of other reasons. Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only. For questions please refer to https://github.com/golang/go/wiki/Questions |
That thread in your shared link discusses "git clone" which I also specified works. "go get" or "go mod tidy" is the one not working, discussed by this bug report. I am re-opening the case. |
|
go invokes git, git operates on the repo, and git + gitlab works without the .git suffix. |
Not true, here is the output of running "go get -x" (prints out each step): Obviously, the line: git ls-remote https://foobar.com/abc/mdx AND running git commands on URLs w/ truncated .git suffix vs gitlab repo is NOT working. |
|
Adding this link to provide evidence from other experts that the ".git" suffix is forcing "us" to reimplement the go.mod and .go code files "import statement", and that git + gitlab does NOT work without the ".git" suffix: |
|
Observe the operation log for go operating on a gitlab repo, |
|
You are feeding it with URL & a public gitlab repo, that is a different use-case. Use my use-case, where you issue "go get -x" so you take go.mod (of current folder) contents and let go get compose the URLs in discovery. Also, I specified private gitlab repo, not public. The public repo approach, it went to "proxy go org" way and can download from there, that is a different use-case than "private" gitlab repo. The go.mod should contain "replace" statement such as: And in gitlabce.com, you have a repo abc/mdx.git with (release) tag v1.1.1. |
|
Go only operates on module paths, not urls. |
|
I am using go 1.23.5 version and I meant module "paths" in this context. I just used the word URL, but technically, a path/URI. Does that work in go 1.23.5? Because 1.24, the one you are using is still not "out", or NOT downloadable from public download sites. |
|
Nothing has changed wrt to invoking mapping module paths for git repos for years. as before, please take troubleshooting your personal setup to a forum. |
|
Another thing, as I originally mentioned, this is a setup where I used "reverse proxy" to create an HTTPs endpoint in front of HTTP endpoint in gitlab repo. So, gitlabce.com/abc/mdx.git is actually resolving to: https://gitlabce.com/abc/mdx.git So, if "go get" truncates the ".git" suffix, then it may behave differently than if gitlab repo is exposed as HTTPs using its HTTPs "feature". Is this setup supported? But isn't it, that we want this to work too? I mean, this is also a valid use-case. For example, gitlab is a service hosted in another service and which, gitlab built-in HTTPs feature is harder to impossible to be setup because of such service under a service layout(TLS certificates for HTTPs require a real host!), then, it will not work. It is a bug in this case, right? I mentioned this, that this is the layout of the setup in the original report. You may be running "go get -x" vs a gitlab repo that is on an HTTPs endpoint natively or directly exposed by gitlab(no reverse proxy!). That may be a different "use-case" altogether. Problem is, if this HTTPs endpoint via "reverse proxy" is not supported, then, IT shops are being forced to implement special hardware/VM for the gitlab so its HTTPs feature for repositories will work w/ "go get"(& go mod tidy). |
|
@seankhliao I am re-opening this bug report & emphasizing that the issue is on HTTPs endpoint in Gitlab where one uses a reverse proxy to map HTTPs to HTTP gitlab repository. "go get"(or go mod tidy) should be able to resolve correctly a module path that ends w/ .git. And the benefits why it is important, ability to use Gitlab as service within a service, which Gitlab can't be given its own network identity & thus, usage of "reverse proxy" to create an HTTPs gitlab module endpoint can be very convenient, life saver in this situation. |
|
Note that gitlab also returns go-import meta tags. a .git suffix is not necessary at all. And if you break gitlab redirects, that's a you / gitlab problem. |
|
It boils down to use-case. Right now, use-case of using reverse-proxy to expose an HTTPs gitlab module repo endpoint is not supported. Because such does not return meta tags making the go get discovery to work. But why do you need that, when go get was given full module path that works? Decision to not support the full path (.git suffix remove) seems a bug from (usage) dev standpoint. Unless there is another unspoken/undocumented reason like security. IT shops are being forced to implement provisioning gitlab with enabled HTTPs (on repo) feature. |
|
Can we reopen this issue because it prevents usage of Gitlab HTTP module endpoint surfaced as HTTPs via reverse proxy, a real world valid setup? Example in my case, I am blocked & team is forced to provision hardware & software for the supported case. Many other shops faced/will face the same scenario. But it is a simple feature support not to truncate “.git” suffix. git commands work on the full module path. Thus isolating it to be a bug in “go get”. |
|
I believe changing the url go uses is a non-starter. [url "ssh://[email protected]/"]
insteadOf = https://example.com/generally, git hosts are flexible in redirecting http paths to one that works, but git/ssh may directly use paths on the filesystem and offer no such flexibility. |
|
The “.git” suffix is a suffix which does not break your example, as that is a feature applied on prefix. Prefix is before the module repo name in its module path. One does not include suffix .git typically, unless it is intended. Specific use in “replace” statements in go.mod. Afaik, it is a targeted edge case. Removal of it(ending or last part, “.git”) in go get in this specific condition described(replace) does look like a bug, bcos if it is intended, why do you decide to override it or does not include it in the list of options tried? Go get tries https then ssh, but does not try the full mod path? It is easily achieved without breaking anything, on this viewpoint. |
|
if a |
|
We are only talking about in https protocol, not in ssh. And in ssh, it does end in .git as well in gitlab. Plus, developer will not specify .git suffix unless it is what it is. Why will you write it in go.mod with .git suffix if it is resolvable without it? There is no proposal to automagically add a suffix. Proposal is to add “taking it as it is” the module path, suffix wise. If I internalize it well, I see the truncation as the bug. You don’t need to truncate the suffix actuallly, simple. And if developer added a suffix when there is not, then that is on us, right? Your tool should be very simple in dealing with the suffix part. |
|
@grecinto - do you have any workaround? I stumbled across similar issue when trying to build OCI containers with privately hosted modules that are used with |
|
Ah, the recommended solution by Go authors is to setup gitlab to have HTTPs feature enabled.
… On Mar 3, 2025, at 6:11 PM, Mikołaj Wieczorkiewicz ***@***.***> wrote:
mwieczorkiewicz
left a comment
(golang/go#71389)
@grecinto - do you have any workaround?
I stumbled across similar issue when trying to build OCI containers with privately hosted modules that are used with replace directive. Interestingly - on macOS it works as intended.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.
<https://github.com/grecinto> <#71389 (comment)> <https://github.com/notifications/unsubscribe-auth/ACLEVVPZGLVVMDK67EBZ3JT2SUDWPAVCNFSM6AAAAABVVPYYDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJWGAYDCMZUGA>
mwieczorkiewicz
left a comment
(golang/go#71389)
<#71389 (comment)>
@grecinto <https://github.com/grecinto> - do you have any workaround?
I stumbled across similar issue when trying to build OCI containers with privately hosted modules that are used with replace directive. Interestingly - on macOS it works as intended.
—
Reply to this email directly, view it on GitHub <#71389 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACLEVVPZGLVVMDK67EBZ3JT2SUDWPAVCNFSM6AAAAABVVPYYDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJWGAYDCMZUGA>.
You are receiving this because you were mentioned.
|
Use-case:
Problem: gitlab repositories are suffixed with ".git", and since "go get" (or "go mod tidy") is truncating the .git part under this use-case (replace statement), it fails discovery phase
Example, a go.mod having "replace" statement to repoint to new repository location in "gitlab" such as:
replace ( github.com/abc/mdx v1.1.1 => foobar.com/abc/mdx.git v1.1.1 )
"git clone .." command works on this HTTPs Gitlab endpoint.
"go get -x" on the folder having this go.mod fails with the following steps printed out:
$ go get -x
cd /home/grecinto/go/pkg/mod
git ls-remote https://foobar.com/abc/mdx
cd /home/grecinto/go/pkg/mod
git ls-remote git+ssh://foobar.com/abc/mdx
Observation: as mentioned above, "go get" truncates the .git suffix thus, discovery fails.
Impact: Prevents continuity of the migrated to Gitlab private repositories and forces update of the go.mod and golang .go files to use the new gitlab full URL in import statements, a very exhaustive refactor work & forces code to Segway farther from the github.com repositories. Can't use just the "replace" statement to repoint and leave the code as is. What it(replace) is meant for.
Originally posted by @grecinto in #71317
The text was updated successfully, but these errors were encountered: