Maven 3.9, unauthorized 401 when reaching MS AZURE repo with PAT

[pawel-ozog]

Hello,

We are using maven docker image to build our app and deploy it as a docker image. Since 16.05.2023 we struggle with the following issue:
dockerfile:
FROM maven as app_builder --> so latest 3.9.x
{copy source files}
{copy settings.xml}
RUN mvn -s settings.xml clean package

We use MS AZURE for our jar repository. settings.xml contains its Personal Access Token auth credentials which is repo_id/token_name/token_value.

The outcome of this build is 401 Unauthorized once trying to download libs from the repo.

This is not the case when I am using:
FROM maven:3.8 as app_builder
or earlier.

This is not the case also when I am using my personal active directory credentials instead of PAT.

Building command:
podman build -t app:v1 -f ./Dockerfile

CentoOS 8 (curl is still <8)
podman v: 4.3.1
java 17.0.2

What might be the case here?
Is it related to the previous vulnerability: https://dso.docker.com/cve/CVE-2023-27536 I assume it is resolved in maven 3.9

[carlossg]

was this working before in maven:3.9 image ?
the change in May 16th was the upgrade to maven 3.9.2 so try maven:3.9.1 and maven:3.9.2 explicitly to see differences
If it broke in 3.9.2 you could check the Maven Jira for known issues

[pawel-ozog]

"was this working before in maven:3.9 image ?"
Yes it was. For ex. 3.8 is working, I was trying 3.5.4 as well.

Tried 3.9.1, 3.9.2, 3.9 none of these works.
But 3.8.7-sapmachine-17 - connects properly.

The only difference in my Dockerfile is:
FROM maven:3.8.7-sapmachine-17 as app_builder
or
FROM maven:3.9.1 as app_builder
or
FROM maven:3.9.2 as app_builder

Looks like to me 3.9.x was changed something comparing to 3.8.x

[carlossg]

"was this working before in maven:3.9 image ?"
Yes it was. For ex. 3.8 is working, I was trying 3.5.4 as well.

you are saying Yes and no at the same time? it never worked in any 3.9., it only worked in 3.8. ?

FROM maven:3.8.7-sapmachine-17 as app_builder
or
FROM maven:3.9.1 as app_builder
or
FROM maven:3.9.2 as app_builder

You are comparing different docker images with different operating system and JVM, can you check the same JVM and different versions of maven? ie.

• maven:3.8.7-eclipse-temurin-17
• maven:3.9.0-eclipse-temurin-17
• maven:3.9.1-eclipse-temurin-17
• maven:3.9.2-eclipse-temurin-17

or any other jdk and version, but the same one, just changing the maven version

You can check in the maven project, it doesn't look like a problem in the docker image though as it seems to be more in Maven itself

[pawel-ozog]

"you are saying Yes and no at the same time?"
Sorry, misunderstood the question. The correct answer is it never worked in any 3.9.

"You are comparing different docker images with different operating system and JVM, can you check the same JVM and different versions of maven?"
As I said before it never worked in any 3.9 any operating system.
But it does with 3.8.x with different operating systems.

"it seems to be more in Maven itself"
It might be. Any idea how can I address this?

[carlossg]

you can ask in maven-users mailing list https://maven.apache.org/mailing-lists.html
or check in Maven jira https://issues.apache.org/jira/projects/MNG/issues

[maffe]

The 401 Unauthorized messages can be misleading. I noticed them too when using a recent Maven version. It happens when Maven asks our GitLab for artifacts which are not present in that repository (for example, JUnit). But it seems only the warnings are new, not the denied requests. By default, when Maven tries to download an artifact, it asks each configured repository until the artifact is found. This leads to unnecessary requests and, under some circumstances with recent Maven, to those warnings.

A way to avoid these unnecessary requests is to use remote repository filtering, introduced in Maven 3.9.0. See also MNG-6763: Restrict repositories to specific groupIds.

Does your build actually fail and are you sure the 401 Unauthorized is the cause (sometimes my build failed and at first it seemed to be because of failed downloads, while the actual cause was something else)? Are the artifacts mentioned in the warnings present in the repository mentioned in the same line of output?