maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tibor Digana <tibordig...@apache.org>
Subject Re: proposal for maven-archetype to switch to dom4j 2.1.1 (and Java 8)
Date Tue, 04 Jun 2019 09:48:57 GMT
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.
> >     > >
> >     >
> >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message