Our organisation is divided into a developer team and support team. Developers have access to all code but support are just guest users and they cannot see the code. The support team have no interest in viewing the code but the releases are very important for them. They want to know all about them and currently there is no way for their access role to view the release page. We want to allow our support team to access the release pages.
At the moment, guest users are forbidden from accessing releases because the visibility is not clear. By allowing intentional access, we document what is exposed and put this decision into the project owners hands where they can make the right call.
Proposal
Guest access to releases is currently disabled due to concerns about exposing information related to the source code.
The correct order of tasks (to turn it on without security vulnerabilities) is:
Prevent guests from guessing tag existence via get ':id/releases/:tag_name' endpoint.
Deprecate get ':id/releases/:tag_name' and introduce get ':id/releases/:id'
The deprecated endpoint get ':id/releases/:tag_name' doesn't allow guests to access. (This endpoint is to be removed in next major version 12.0)
The new endpoint get ':id/releases/:id' allows guests to access
Fix Entities::Release not to leak repository information to guests. i.e. Add permission check to commit, tag_name attributes.
@markglenfletcher All our projects are created as private projects and cannot be accessed unless you are invited. When I try to access them as an invited guest user there is no 'release page' tab for the project.
Some clarifications about how we want to use the release page:
Guest users need to have access to the release page.
Guest user should not have access to download release code. They don't have access to view the code in the repo so they should not be permitted to download it at any place.
Our releases contains a package of binary files and these should be available to download from the release page by guests.
We want to link directly to the closed issues/MR in the release notes.
Our releases are tagged on format vx_y_z and for every such tag we want to create a release. It would be nice if it was automatically generated at the release page.
All release notes follow the same layout and it would be nice to base the notes on a global template.
It is not necessary for our developers to have a code download link at the release page as they prefer to go strait into the repository page instead.
@filipa @dosuken123 can you please take a look and ask questions/confirm feasibility of this issue as we head into finalizing scope for 11.11? cc @rverissimo - I don't think there's UX here more than enabling the access, but FYI.
Implement functionality to set permission role for the release page. In order to make this work we need to ensure guest users, who do not have access to the code, are not exposed to code information.
It seems that we want to set a permission role through the interface. My guess is that we would be adding a field in the permissions settings:
Deprecate get ':id/releases/:tag_name' and introduce get ':id/releases/:id'
@dosuken123 I think we can't have these two routes coexisting together, right? One of them will always take precedence and break calls to the other. We'll need to do something like find_by_tag || find_by_id or chose different route for the new endpoint.
This endpoint is mainly used for Release page rendering (i.e. internal usage) so that there is not so much usecase as a public API endpoint. If so, we might be able to drop it immidiately.
This endpoint is mainly used for Release page rendering (i.e. internal usage) so that there is not so much usecase as a public API endpoint. If so, we might be able to drop it immidiately.
@dosuken123 Can we really do this? This is a public endpoint and even if we check its usage on GitLab.com there is no way to find this for self-managed instances so we can potentially break things.
Deprecate get ':id/releases/:tag_name' and introduce get ':id/releases/:id'
I think at this time the simplest thing we can do is to go with https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/27247 - this MR will allow guests to access Releases from the UI but still prevent them to guess tag existance using the API which is something we want to do anyway no matter what we decide about the API endpoint. Guest users using the API is probbaly not very common use case anyway. @jlenny What do you think about this?
Can we really do this? This is a public endpoint and even if we check its usage on GitLab.com there is no way to find this for self-managed instances so we can potentially break things.
I basically don't recommend this, however, if we go down the pessimistic path, we'd need several milestones to complete the task to resolve the whole ~"technical debt" , and my question is if keeping the backward compatibility on the relatively new public endpoint is worth trying. This GET endpoint was added for frontend rendering as the main reason, which totally makes sense, but now think about a situation that users have to use this public endpoint directly, instead of accessing the dedicated Releases page. I cannot imagine it TBH.
The POST/PUT releases/:tag will not be changed, which should stay intact because users cannot create release entries without the endpoint. If we change this, it's a breaking change, and thus we don't step into it.
We can always try to communicate in a blog post that they need to update the public endpoint if they use it.
BTW where do we use that endpoint internally? I fail to find such case, the Releases page is using GET /projects/:id/releases to get the list of releases.
BTW where do we use that endpoint internally? I fail to find such case, the Releases page is using GET /projects/:id/releases to get the list of releases.
I think we don't use this endpoint today. Probably we added it for the consistency sake with POST/PUT releases/:tag_name.
I think we should add filter param to GET releases, instead of removing the endpoint.
Guest users can access Release pages for downloading assets but are not allowed to download the source code
But this is not true in our projects: Guests can download the source code. This is because the project is internal. So the documentation is a little misleading here