Hi, if dom4j is problematic I can try to remove that old dependency. We use it internally in 2 placea (in fact almost only one simple method) - to manage <modules/> element in pom.xml
Sylwester W dniu wt., 4.06.2019 o 09:36 Homer, Tony <[email protected]> napisał(a): > >>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. > > > > > > > >
