# Problem Go offers a limited support for authentication of private Go modules: * HTTPS (via netrc) * SSH (with a modification of `.gitconfig` file) ## HTTPS [By default, Go documentation](https://go.dev/ref/mod#private-module-proxy-auth) recommends to use HTTPS authentication. It requires users to create a `.netrc` file with credentials. It will authorize `go get` requests for private Go modules. However, this approach doesn't work for everyone. The main problem that the credentials must be stored on the machine in plaintext in order to work. ## SSH To solve that the [Go documentation](https://go.dev/doc/faq#git_https) provides an alternative - SSH authentication instead of HTTPS. * It works as expected for flat namespaces (like `namespace/project`). * But it causes problems for nested namespaces. ## Nested namespaces problem The root cause is `go get` implementation. In order to use SSH authentication, `go get` needs to know where the project is located. For project in `namespace/subgroup/project`, `go get` will send following requests: * `GET https://gitlab.com/namespace/subgroup/project?go-get=1` * `GET https://gitlab.com/namespace/subgroup?go-get=1` * `GET https://gitlab.com/namespace?go-get=1` These requests are not authorized (if `.netrc` is missing), because of that GitLab cannot respond with a correct link to the project (`https://gitlab.com/namespace/subgroup/project.git`). Instead we return `https://gitlab.com/namespace/subgroup.git` as a link. Then, Go tries to `git clone` repository using SSH authentication `ssh://gitlab.com/namespace/subgroup.git`. It fails because the repository doesn't exist. As a result, for Go private projects in nested namespaces user must have HTTPS authentication. :disappointed: ## Current solution I discovered a workaround(?) for this problem. Go won't send `go get` requests if the module name contains `.git`. It will directly try to clone the repository and skip the HTTPS authentication step. ```go import "gitlab.com/namespace/subgroup/project.git" ``` :heavy_minus_sign: However, it will require users to update the codebase to use `.git` in module names. ## Proposal Allow users to set a group for private Go modules. For example, on the instance and maybe top group level.  Then, GitLab will be able to correctly discover a path to Go modules even without a HTTPS authentication. The final path to the project will look like this: `gitlab.com/namespace/go-modules/project` :heavy_plus_sign: Users don't have to set `.git` in their module names.