maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Homer, Tony" <tony.ho...@intel.com>
Subject Re: proposal for maven-archetype to switch to dom4j 2.1.1 (and Java 8)
Date Tue, 04 Jun 2019 06:36:45 GMT
>>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
View raw message