>>But there is one thing I do not understand why such upgrade is so important >>for the users even if overriding the dependency in user's POM is so simple. >>Do you inherit from this project and you need dom4j as transitive dependency?
I suppose you did not ask me, but I thought I'd share the background on why I proposed this change. My team maintains an eclipse product which depends on m2e which in turn depends on maven-archetype to provide dom4j. I originally proposed that m2e update to dom4j 2.1.1 [1], but because m2e gets dom4j from maven-archetype, Mickael asked me to instead request that maven-archetype update to 2.1.1. As for why I need this update, our company policy does not allow us to release software containing CVEs with CVSS v2 > 4.0. I believe that the thinking is that even if the CVE is not actionable in the specific case (as you suggested is the case here), some customers will refuse to use the software because retaining the CVE version shows poor security hygiene. In any case, I have no control over this policy. I have been working around this issue by forking m2e and updating it to use dom4j 2.1.1 myself, but I'd like to stop doing this and use the upstream version instead. In order to achieve this, I logged the issue with m2e-core and opened a PR (as mentioned above), then logged an issue with maven-archetype and opened a PR (which is essentially what we are discussing here). Tony [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=547337 On 6/3/19 , 2:45 PM, "Tibor Digana" <[email protected]> wrote: @Mickael Istria @Eric Lilja <[email protected]> @Elliotte Rusty Harold We are the maintainers. But there is one thing I do not understand why such upgrade is so important for the users even if overriding the dependency in user's POM is so simple. Do you inherit from this project and you need dom4j as transitive dependency? Having a look in the CVE-2018-1000632 ( https://www.cvedetails.com/cve/CVE-2018-1000632/), the root of security fix in DOM4J 2.1.1 is called "XML Injection on element and attribute". The issue talks about names of element where you pass character like "<". Do we use such element name in this project? No! Because it is hard coded string in our code: .addElement( "modules" ) .addElement( "module" ) The classes of DOM4J is used in method stack and not exposed outside. The security fix simply throws an exception in case of using "<" in qname. The question is why the pressure is made high in maven-archetype, even if we see that the base of the security fix cannot improve our life. Resources: https://www.cvedetails.com/cve/CVE-2018-1000632/ https://ihacktoprotect.com/post/dom4j-xml-injection/ https://github.com/dom4j/dom4j/issues/48 Cheers Tibor On Mon, Jun 3, 2019 at 7:47 PM Eric Lilja <[email protected]> wrote: > +1, people on old versions of Java can remain on the old version of the > plugin. No one who is in a project where an old version of Java is still in > use (< 8) expect to have everything else in their eco-system (3PPs, maven > plugins etc) at bleeding edge versions. I guess many such projects are many > versions behind on even supported releases...particularly regarding Maven > plugins. > > - Eric L > > On Mon, Jun 3, 2019 at 7:23 PM Mickael Istria <[email protected]> wrote: > > > People who don't want to update are the ones who have to pay the effort, > > not the project that tries to ship a security fix. > > The simplest past forward is the one provided by Tony. Customers who > don't > > want to use it can remain on previous version of the archetype plugins. > > Other proposals to fix it are just more time-consuming without providing > > value to Maven project. > > >
