maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrico Olivelli <eolive...@gmail.com>
Subject Re: proposal for maven-archetype to switch to dom4j 2.1.1 (and Java 8)
Date Tue, 04 Jun 2019 10:16:42 GMT
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 <tibordigana@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 <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