Skip to content

Allow go-getting projects in subgroups

GitLab supports the vanity import path feature of go get. The way it works is that when you request a repository URL with the parameter go-get=1 (like go get does automatically), you get a page with just a go-import meta tag pointing to the Git URL for that repository. (Example) Note that this works for subdirectories too (Example) and still points to the Git URL of the repository, so the page has to understand where the repository path ends and the subdirectory path begins.

Before GitLab supported subgroups, this was a simple string replacement (the subdirectory path always began after the first two path components: group/project).

Now that there are subgroups, GitLab actually has to do a lookup to find whether we're dealing with group/project/subdirectory or with group/subgroup/project.

This functionality is already handled by go.rb, but it only works if the authenticated user has access to the requested project. Since go get will not authenticate to GitLab, this basically never works.

I would like to put up for discussion to lift this restriction to allow projects in subgroups to be imported by go get. This comes with a small privacy tradeoff: It would allow unauthenticated users to discover whether a certain project in a subgroup exists or not.

I for one think the tradeoff is worth it, so currently after each GitLab update I replace return unless Ability.allowed?(current_user(request), :read_project, project) with return unless project.