Maven package registry access with Gradle using Personal Access Tokens is inconsistent.

Summary

Maven package registry access is inconsistent.

  1. Personal Access Token with read_api scope does give access if building via Gradle with empty Gradle cache using project/group-ids.
  2. Personal Access Token with read_api scope does not give access if building via Gradle with primed Gradle cache using project/group-ids. Gradle fails during https HEAD call.

Documentation https://docs.gitlab.com/ee/user/packages/maven_repository/index.html is not precise regarding authentication for a) using a maven registry for dependencies and b) publishing. In a), read-only should suffice. In b), you should need write permission. See https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/packages/maven_repository/index.md#L278.

Also, documentation for read_api under https://gitlab.com/-/profile/personal_access_tokens means that it should be possible to use read_api tokens only when using maven registry for dependencies. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/locales/doorkeeper.en.yml#L80.

Steps to reproduce

  1. Place a maven package in a Gitlab Maven package registry.
  2. Create a gradle project with a dependency to that maven package.
  3. Authenticate with a personal access token with read_api scope, and use the group/project id in the registry path.
  4. The build will succeed if there is no prior Gradle cache.
  5. The build will fail if there is a primed Gradle cache.

Example Project

https://gitlab.com/maven-registry-test/libraryconsumer

What is the current bug behavior?

When gradle cache is empty, gradle succeeds.

When gradle cache is primed, and refresh cache is triggered, gradle fails with the error (example):

Could not HEAD 'https://gitlab.com/api/v4/ ... pom'. Received status code 403 from server: Forbidden

What is the expected correct behavior?

The gradle build should succeed in both cases (if it is the intended behaviour that read_api should indeed give read access to the maven package registry, as stated in https://gitlab.com/-/profile/personal_access_tokens).

Current work-around

Use personal access tokens with api (i.e. read/write) scope, or use deploy or job tokens.

Relevant logs and/or screenshots

See example project for full logs.

$ ./gradlew classes
Downloading https://services.gradle.org/distributions/gradle-6.6.1-bin.zip
.........10%..........20%..........30%..........40%.........50%..........60%..........70%..........80%..........90%.........100%
Welcome to Gradle 6.6.1!
Here are the highlights of this release:
 - Experimental build configuration caching
 - Built-in conventions for handling credentials
 - Java compilation supports --release flag
For more details see https://docs.gradle.org/6.6.1/release-notes.html
Starting a Gradle Daemon (subsequent builds will be faster)
> Task :compileJava
> Task :processResources
> Task :classes
BUILD SUCCESSFUL in 58s
2 actionable tasks: 2 executed
$ ./gradlew clean classes --refresh-dependencies
> Task :clean
> Task :compileJava FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':compileClasspath'.
   > Could not resolve com.trifork.sandbox:library:0.0.1.
     Required by:
         project :
      > Could not resolve com.trifork.sandbox:library:0.0.1.
         > Could not get resource 'https://gitlab.com/api/v4/groups/10202943/-/packages/maven/com/trifork/sandbox/library/0.0.1/library-0.0.1.pom'.
            > Could not HEAD 'https://gitlab.com/api/v4/groups/10202943/-/packages/maven/com/trifork/sandbox/library/0.0.1/library-0.0.1.pom'. Received status code 403 from server: Forbidden
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 34s

Output of checks

This bug happens on Gitlab.com.

Possible fixes

  1. Make HEAD http(s) calls to maven registries respect the same access control policies as GET calls.
  2. Update documentation on https://docs.gitlab.com/ee/user/packages/maven_repository/index.html to make it clear that different permissions are required for using a maven registry as a dependency (read-only) and publishing to a maven registry (read/write).
Edited by Dirk Hasselbalch