[MNG-6965] Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath

[jira-importer]

Mark Nolan opened MNG-6965 and commented

A simple minimal archetype pom following the manual pages downloads plexus-utils 1.1, even though it is not (apparently) declared anywhere. This version is banned at my organization (edited to add: due to vulnerabilities), meaning such a pom always fails.

 

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
  http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>test</groupId>
<artifactId>test</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>maven-archetype</packaging>
<name>test</name>

<build>
  <extensions> 
    <extension>
      <groupId>org.apache.maven.archetype</groupId>
      <artifactId>archetype-packaging</artifactId>
      <version>3.1.2</version>
    </extension>
  </extensions>

  <pluginManagement>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-archetype-plugin</artifactId>
        <version>3.1.2</version>
      </plugin>
    </plugins>
  </pluginManagement>
</build>
</project>

Running any goal, such as mvn -X clean, produces the following before the goal is executed:

[DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800, ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1, ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700, ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0, ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1, DefaultDependencyCollector.collectTime=66890900, DefaultDependencyCollector.transformTime=8523500}
[DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
[DEBUG]    org.codehaus.plexus:plexus-utils:jar:1.1:runtime

 

As far as I can see, there is no declared dependency on plexus-utils:1.1.

 

---

Affects: 3.0-alpha-3, 3.0, 3.6.0, 3.6.3

Attachments:

• pom.xml (1.36 kB)

Issue Links:

• MNG-7115 MavenITmng5771CoreExtensionsTest fails on maven-3.8.x branch
  ("fixes")

• MSKINS-220 cannot build with Maven 3.9
  ("causes")

• MNG-7097 Plugin Dependency Resolution: don't download Maven-provided artifacts

• MNG-2892 Use shade to hide the use of plexus-utils internally so that plugins can use their own version
  ("is broken by")

• MNG-3819 [regression] Plugins that don't declare dependency on plexus-utils no longer get plexus-utils:1.1
  ("supercedes")

Remote Links:

• GitHub Pull Request #57
  
• GitHub Pull Request #173
  
• GitHub Pull Request #73
  
• GitHub Pull Request #367
  
• GitHub Pull Request #755
  

Backported to: 4.0.0-alpha-2, 3.9.0

1 votes, 14 watchers

[jira-importer]

Michael Osipov commented

Why do you consider this to be a bug? It is obviously a transitive dependency, isn't it?

[jira-importer]

Dennis Lundberg commented

I guess that the reason it is banned is because of vulnerabilities?

https://snyk.io/vuln/maven:org.codehaus.plexus%3Aplexus-utils

A good way to find out from where a dependency is pulled in is to use this command on the project that is pulling the dependency in question. In this case archetype-packaging:

mvn dependency:tree

[jira-importer]

Dennis Lundberg commented

I can confirm that plexus-utils:1.1 gets downloaded using Maven 3.6.3 with a clean repo and the command line:
mvn clean
for the attached project.

However I have not been able to establish why. 

[jira-importer]

Mark Nolan commented

 

Why do you consider this to be a bug? It is obviously a transitive dependency, isn't it?

 

Because I cannot find any declaration of this as a dependency. It is not declared in the pom for archetype-packaging and the parent has a dependencyManagement section with 3.2.0 declared. But there is simply no reference to it in a dependencies section as far as I can see. Also, it is a very old version and I can't find any other recent dependencies on this version.

 

Dennis Lundberg, as I think you've found by now, dependency:tree doesn't reveal anything because it is not a transitive dependency of the project. And dependency:resolve-plugins also doesn't reveal anything because it is not a dependency of any of the plugins. I am not really familiar with how Maven resolves different packaging, but it looks like that is where it is being evaluated. And, yes, it is the vulnerabilities that prevent me using plexus-utils:1.1

 

 

[jira-importer]

Mark Nolan commented

 

If I create a version of the extension (archetype-packaging) with an explicit dependency on plexus-utils, it is resolved by the parent pom to be version 3.2.0, which works fine.

[jira-importer]

Dennis Lundberg commented

My guess is that the components.xml file used to declare Plexus components, somehow has a (runtime?) dependency on plexus-utils. We need someone who knows Plexus to answer this.

[jira-importer]

Sylwester Lachiewicz commented

It's injected by https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/internal/PlexusUtilsInjector.java

[jira-importer]

Mark Nolan commented

 

It's injected by https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/internal/PlexusUtilsInjector.java

 

Well, having looked at that and read the comment in the code, I am left somewhat in disbelief! It is extraordinary to have such a fixed dependency.

 

I realise that the situation of plexus-utils:1.1 being blocked may be a specific situation for my company, but we cannot be unique. That version is very old and it has multiple vulnerabilities. It isn't fit for purpose in a corporate environment. Indeed, we should all be avoiding vulnerable software and baking in such a dependency is a bad idea.

 

But, in addition, this seems like a very poor way to solve the problem. If a plugin (in this case an extension, but I assume the same process applies) requires a dependency on plexus-utils, then that should be enforced, not slipped in under the covers.

 

My proposals for resolving this would be, in order of preference:

1. This is required for Maven 2.x compatibility. Simply remove it. Maven 2 was EOL 2014.
2. If extensions continue to have an implicit dependency on plexus-utils, make it explicit. All extensions and plug-ins must declare such a dependency or fail. Change the injector to throw an exception if the dependency is not found.
3. If really worried about how many are using this implicit dependency, then at least make it respect any dependencyManagement declaration. In this case, that would result in 3.2.0 being used by archetype-packaging.
4. Add an explicit dependency to archetype-packaging so that the version of plexus-utils respects the version in the parent pom.

 

I don't see "do nothing" as an option.

 

[jira-importer]

Michael Osipov commented

Pushed an IT branch, down to:

[ERROR] Failures:
[ERROR]   MavenITmng2749ExtensionAvailableToPluginTest>AbstractMavenIntegrationTestCase.runTest:255->testitMNG2749:62
[ERROR] Errors:
[ERROR]   MavenITmng6772NestedImportScopeRepositoryOverride>AbstractMavenIntegrationTestCase.runTest:255->testitInDependency:74 » Verification
[ERROR]   MavenITmng6772NestedImportScopeRepositoryOverride>AbstractMavenIntegrationTestCase.runTest:255->testitInProject:57 » Verification
[INFO]
[ERROR] Tests run: 849, Failures: 1, Errors: 2, Skipped: 0

[jira-importer]

Michael Osipov commented

After rebasing, I am down to:

[ERROR] Failures:
[ERROR]   MavenITmng2749ExtensionAvailableToPluginTest>AbstractMavenIntegrationTestCase.runTest:255->testitMNG2749:62
[INFO]
[ERROR] Tests run: 849, Failures: 1, Errors: 0, Skipped: 0

[jira-importer]

Michael Osipov commented

I am hanging for hours trying to understand why Plexus Utils is necessary. I think there is some hidden exception which make the loading fail for the IT MNG-2749. OR the entire IT is conceptionlly broken.

[jira-importer]

Michael Osipov commented

Found it, last issue is gone. All Its pass now.

[jira-importer]

Michael Osipov commented

Folks, PR and IT PR updated. Please have a look. Works for me now.

[jira-importer]

Michael Osipov commented

Fixed with c61e63032f71c32c4060c8a94ce792bf47824e3c and 068dcf29118ebc462368afd94cfae2ae52b8d71b.

[jira-importer]

Patrick Markiewicz commented

I know this is an old thread.  I see the Fix Version is 4.0.0.  Is there any workaround for this issue prior to 4.0.0?  Many thanks.