Downloading nuget packages via the group API endpoint fails for accounts with less than reporter access at the group level
Summary
Customer's developers are using Maven and Nuget packages.
They are assigned the following access:
- Projects, they have developer access
- The group(s) containing the projects, no access.
They've configured the group API endpoint in their application builds to obtain dependencies etc.
For Maven, this works - developers can build using this configuration.
For Nuget, dotnet add package
fails:
info : Restoring packages for /builds/test/foo/nuget/nuget-repository/Target/Target.csproj...
error: NU1301 Unable to load the service index for source https://gitlab.example.com/api/v4/groups/100/-/packages/nuget/index.json.
error: Response status code does not indicate success: 403 (Forbidden).
or
info : Restoring packages for C:\Target\Target.csproj...
error: Unable to load the service index for source https://gitlab.example.com/api/v4/groups/100/-/packages/nuget/index.json.
info: Packet 'demo1' is compatible with all the specified frameworks in project 'C:\Target\Target.csproj'
error: Value cannot be null. (Parameter 'version')
GitLab team members can read more in the ticket.
Workaround
Giving developers guest access to the group doesn't resolve this.
It's necessary to provide reporter access, then the group API endpoint works.
Example Project
This project can be deployed to reproduce this issue, but since it's in a public group, it doesn't reproduce the issue 'in situ'
https://gitlab.com/bprescott-support/testing/issue-386804-nugetgroupapi
Steps to reproduce
- Create a private subgroup
- Fork or clone the example project into it
- Add a CI variable to the project
- name:
GROUP_ID_FOR_CI
- value: the numeric ID for the group, since this is used for accessing the group package api endpoint
- type: variable
- environment scope: all
- untick "protect variable"
- do not tick "mask variable"
- name:
- Run a pipeline off master (to prove the jobs generally work)
- manually run the
maven-repository
andnuget-repository
jobs to create packages in the project - manually run the deploy stage to consume those packages via the group API endpoints
- manually run the
- Add a test account as a direct member to the project only; developer access. It should have no inherited access to the project or the parent group
- Using the test account
- run a pipeline on the
directmember
branch - manually run the
maven-repository
andnuget-repository
jobs to create packages in the project - manually run the deploy stage to consume those packages via the group API endpoints
- run a pipeline on the
What is the current bug behavior?
I suspect the issue here is that for nuget, index.json
is pulled from the group API endpoint, and then the package itself is pulled from the project API endpoint (I assume it gets this information from index.json
)
Comparing the raw job logs for the examples linked about
-
Developer account: failedjob.log
$ dotnet add package TestPackage --package-directory ../../.nuget/packages Determining projects to restore... Writing /tmp/tmpZaXw1e.tmp info : Adding PackageReference for package 'TestPackage' into project '/builds/bprescott-support/testing/issue386804/nugetgroupapi/nuget-repository/Target/Target.csproj'. info : Restoring packages for /builds/bprescott-support/testing/issue386804/nugetgroupapi/nuget-repository/Target/Target.csproj... error: Unable to load the service index for source https://gitlab.com/api/v4/groups/61966082/-/packages/nuget/index.json. error: Response status code does not indicate success: 403 (Forbidden). Usage: NuGet.CommandLine.XPlat.dll package add [options] Options:
-
Owner account: successjob.log
$ dotnet add package TestPackage --package-directory ../../.nuget/packages Determining projects to restore... Writing /tmp/tmpg9KO7b.tmp info : Adding PackageReference for package 'TestPackage' into project '/builds/bprescott-support/testing/issue386804/nugetgroupapi/nuget-repository/Target/Target.csproj'. info : Restoring packages for /builds/bprescott-support/testing/issue386804/nugetgroupapi/nuget-repository/Target/Target.csproj... info : GET https://gitlab.com/api/v4/groups/61966082/-/packages/nuget/metadata/testpackage/index.json info : OK https://gitlab.com/api/v4/groups/61966082/-/packages/nuget/metadata/testpackage/index.json 226ms info : GET https://gitlab.com/api/v4/projects/42208310/packages/nuget/download/TestPackage/1.0.0+3538144027/testpackage.1.0.0+3538144027.nupkg info : OK https://gitlab.com/api/v4/projects/42208310/packages/nuget/download/TestPackage/1.0.0+3538144027/testpackage.1.0.0+3538144027.nupkg 241ms info : Installed TestPackage 1.0.0+3538144027 from https://gitlab.com/api/v4/groups/61966082/-/packages/nuget/index.json with content hash E+8vgDmsq4AzLW2Ahy+dvq4zCUDZL5a47+NflIowLw2yHY3UbTWt7hybSniHH+iatthKZYxndfIt4ERYK/mkvw==. info : Package 'TestPackage' is compatible with all the specified frameworks in project '/builds/bprescott-support/testing/issue386804/nugetgroupapi/nuget-repository/Target/Target.csproj'.
Whereas for Maven, there isn't the intermediate step of pulling metadata.
- Maven raw job logs:
- Owner account: maven-owner.log
- Developer account: maven-developer.log
What is the expected correct behavior?
The group API endpoint works consistently across all package types
Relevant logs and/or screenshots
Output of checks
15.5.4
This bug happens on GitLab.com - GitLab Enterprise Edition 15.8.0-pre d5b1b283
- Reproduced in this project: https://gitlab.com/bprescott-support/testing/issue386804/nugetgroupapi
- This is necessarily private! The job logs attached above were generated there.