Yep I going to merge the upgrade patch as soon as I am back from vacation https://github.com/apache/maven-archetype/pull/28
Enrico Il mar 4 giu 2019, 11:49 Tibor Digana <tibordig...@apache.org> ha scritto: > Sylwester, removing dom4j and substituting by Java XML API would be the > best choice. > Pls then inform the guys in > https://github.com/apache/maven-archetype/pull/28 because I think they are > handling it in parallel with you. > Cheers > Tibor > > On Tue, Jun 4, 2019 at 8:46 AM Sylwester Lachiewicz <slachiew...@gmail.com > > > wrote: > > > 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 <tony.ho...@intel.com> > > 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" <tibordig...@apache.org> wrote: > > > > > > @Mickael Istria > > > @Eric Lilja <mindcoo...@gmail.com> > > > @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 <mindcoo...@gmail.com> > > > 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 < > mist...@redhat.com> > > > 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. > > > > > > > > > > > > > > > > > > > > >
