Guest users can't access the dedicated Release page
Summary
In #34862 (closed), we fixed a bug that prevented Guest users from viewing a private project's Releases page.
Unfortunately the fix (!28447 (merged)) uncovered another, similar problem: Guest users will get an error when clicking the title of a Release to view the "dedicated" Release page.
Steps to reproduce
- Create a new private project
- Create a new Release in this project
- Add a user to the project with Guest permissions
- Log in as the Guest user and navigate to the project's Releases page
- Click the title of a Release to navigate to the "dedicated" page for this Release
What is the current bug behavior?
The user gets a "Something went wrong while getting the release details" error message:
What is the expected correct behavior?
Either:
- The user does not get an error and the Release is rendered identically as it is on the main Releases page, or
- The Release title is not rendered as a link on the main Releases page, so the user can not access the dedicated Release page.
Output of checks
This bug happens on GitLab.com.
Root cause
This is actually a much larger issue, because:
- Releases are inextricably tied to Git tags; the tag name is used as the primary identifier for routing purposes
- Guest users are not allowed to access any Git-related information in private projects, including tags
For example, the URL to the dedicated Release page looks like https://example.gitlab.com/user/project/-/releases/tag
. However, Guest users don't have access to tags, so they cannot access this URL.
In fact, this is a small security issue: as shown in the screenshot above, we are leaking the tag name test
through the breadcrumb to a user with Guest permission.
This also has implications for features like "search by Release" and the milestone "issue summary", all of which rely on URLs that include Git tag names.
Solutions
0. Allow guest users to know tag names associated with releases
From this comment. Currently, we have:
expose :name do |release, _|
can_download_code? ? release.name : "Release-#{release.id}"
end
expose :tag, as: :tag_name, if: ->(_, _) { can_download_code? }
in the API, and
get ':id/releases/:tag_name', requirements: RELEASE_ENDPOINT_REQUIREMENTS do
authorize_download_code!
on the dedicated release page api.
If we just remove these conditions, we can allow users to visit the dedicated release pages without some of the content. Users still won't be able to:
- download code
- see commit hash
- download evidence
There are a few ways we can address this bug (and all other related issues):
1. Make tag information available to Guest users
This would be the simplest solution, since it would allow Releases to behave more-or-less identically for Guest users as they do for Developers, Maintainers, etc.
However, this probably isn't an option, as this would be a change in security policy. But it might be worth investigating.
2. Always reference Releases by ID, not tag name
If we used the Release ID as its primary identifier instead of its tag name, this issue would go away. For example, a Release with a URL like https://example.gitlab.com/user/project/-/releases/v1.2
would instead be accessed with a URL like https://example.gitlab.com/user/project/-/releases/2345
.
This isn't as convenient or as nice to look at, but it would allow Guest users to interact with Releases without exposing the Release's associated tag.
A change like this has the potential to involve a lot of development work.
3. Always reference Releases by some other unique identifier
Exactly the same as number #2 above, except using a unique identifier other than the Rails ID. For example, we could add a first-class "version" concept and use this version as a primary identifier: #213838
4. Lock down Releases for Guest users
A third option is to simply remove any feature that references tag names for Guest users. While this probably makes the most sense, it's unfortunate because almost all features use tag names in some way, so the experience for Guest users will be very crippled. For example, Guest users:
- won't be able to search issues or merge requests by Release
- won't be able to click on issue or merge request counts in the "issue summary" section of Release blocks
- won't have access to the "dedicated" Release page
- For example, if a Developer sends a link to a "dedicated" Release page to a Guest, they will get a "404 - Page not found" error, which isn't intuitive since the Guest has access to the Release on the main Releases page