maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elliotte Rusty Harold <elh...@ibiblio.org>
Subject Re: proposal for maven-archetype to switch to dom4j 2.1.1 (and Java 8)
Date Tue, 04 Jun 2019 10:42:22 GMT
FYI, I took a  look at the code and found it is already using both
dom4j AND JDOM, even in the same class:

https://github.com/apache/maven-archetype/blob/0fd806f773354ec62c8eb40f624d78a218815506/archetype-common/src/main/java/org/apache/maven/archetype/common/DefaultPomManager.java

This is dependency bloat. Even if security issues weren't in play, I'd
recommend ripping out dom4j and using JDOM exclusively.

On Tue, Jun 4, 2019 at 5:49 AM Tibor Digana <tibordigana@apache.org> wrote:
>
> 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 <slachiewicz@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.homer@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" <tibordigana@apache.org> wrote:
> > >
> > >      @Mickael Istria
> > >     @Eric Lilja <mindcooler@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 <mindcooler@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 <mistria@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.
> > >     > >
> > >     >
> > >
> > >
> > >
> >



-- 
Elliotte Rusty Harold
elharo@ibiblio.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message