Maven package registry, group level endpoint: separate user permissions from finder

🔥 Problem

The Maven Repository exposes an API endpoint at the group level that allows maven clients to download files from a specific package (name+version specified).

The logic is quite simple:

1. locate the package within the group.
2. locate the file within that package.

The problem is that in (1.) we mix in user permissions. This means that while locating the packages, we only check projects where the user is at least reporter.

Now add duplicated packages within the target group (eg. same package name+version in two different sub projects), what will happen?

Well, first the maven package finder will always return the most recent package.

The problem is the set on which this "most recent" filter is applied. This set depends on user permissions.

Imagine the following situation:

graph LR
    G[Group] --> PA((Project A))
    G[Group] --> PB((Project B))

Let's say that the maven package test 1.2.3 exists in both packages but:

• on Project A, it has been published 10 days ago.
• on Project B, it has been published 3 days ago.

For a user that has at least reporter on both projects: asking for test, 1.2.3 at Group level will return package from Project B. The user "sees" both packages and the Maven Repository returns the most recent one.

For a user that has reporter on Project A but has guest on Project B: asking for test, 1.2.3 at Group level will return package from Project A. 💥 . The users "sees" only the package from Project A. The most recent one for that set is from Project A.

This is a confusing situation.

🚒 Solution

While executing (1.) decouple finding the most recent package from user permissions:

1. Locate the most recent with the group.
2. Check user permissions with the found package's project.
3. Locate the file within that package.

Regarding the request forward, do it only if (1.) reports no package found.

⚠ breaking change

This is a breaking change as users with not enough permissions will get rejected in (2.) whereas currently, they can get a different package. Some user workflows could depend on this buggy behavior and so reject the request in (2.) could introduce issues.