Re: proposal for maven-archetype to switch to dom4j 2.1.1 (and Java 8)

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: proposal for maven-archetype to switch to dom4j 2.1.1 (and Java 8)

Elliotte Rusty Harold
Who's the maintainer? Sometimes a friendly ping through back channels
can work wonders.

On Mon, Jun 3, 2019 at 12:46 PM Homer, Tony <[hidden email]> wrote:

>
> >>Perhaps ask the dom4j developers first to see if a 2.0.3 release can be scheduled.
> FWIW, there was an issue logged asking for that on 6 December 2018 [1].
> I noted this in the PR as well [2] as an explanation for the bump to 2.1.1 and Java 8.
> Just making sure this information is part of the discussion. (
>
> [1] https://github.com/dom4j/dom4j/issues/55
> [2] https://github.com/apache/maven-archetype/pull/28
>
>
> On 6/3/19 , 7:59 AM, "Tibor Digana" <[hidden email]> wrote:
>
>     First of all, this PR was create because of vulnerability CVE-2018-1000632.
>     Vulner or non-vulnerability, the version of javac for dom4j:1.6.1 is not an
>     argument for me.
>     If some code was broken in that version, it would be an argument. But it is
>     not an argument to infinitely grow versions only because somebody in CVE
>     wants to. This really is pushing hard to sell technologies and not a common
>     sense.
>
>     T
>
>     On Mon, Jun 3, 2019 at 4:48 PM Elliotte Rusty Harold <[hidden email]>
>     wrote:
>
>     > I know there are plenty of places at Java 8+. There are also many who
>     > haven't gotten that far. Some of my day job involves Java 7+ clients,
>     > and I know of others even further back than that.
>     >
>     > On Mon, Jun 3, 2019 at 10:38 AM Gary Gregory <[hidden email]>
>     > wrote:
>     > >
>     > > FWIW, we are talking at work about Java 8 and 11 only these days. Java 7
>     > is
>     > > in the distant past. Most people can't even get Java 7 updates since it
>     > is
>     > > EOL unless you pay.
>     > >
>     > > Gary
>     > >
>     > > On Mon, Jun 3, 2019 at 10:35 AM Elliotte Rusty Harold <
>     > [hidden email]>
>     > > wrote:
>     > >
>     > > > I agree that this should be fixed. I'm not yet convinced that
>     > > > requiring Java 8 and upgrading to dom4j 2.1 is the bets fix.
>     > > >
>     > > > On Mon, Jun 3, 2019 at 10:24 AM Enrico Olivelli <[hidden email]>
>     > > > wrote:
>     > > > >
>     > > > > Elliotte,
>     > > > >
>     > > > > Il giorno lun 3 giu 2019 alle ore 15:59 Elliotte Rusty Harold <
>     > > > > [hidden email]> ha scritto:
>     > > > >
>     > > > > > Perhaps ask the dom4j developers first to see if a 2.0.3 release
>     > can
>     > > > > > be scheduled.
>     > > > > >
>     > > > > > And if that doesn't work, how much effort is it to switch off of
>     > dom4j
>     > > > > > completely?
>     > > > > >
>     > > > > > maven-archetype strikes me as too important to drop Java 7
>     > > > > > compatibility this soon.
>     > > > > >
>     > > > >
>     > > > > Are you -1 with this change ?
>     > > > > If an user wan't to use java 7 he can use current version of the
>     > plugin.
>     > > > >
>     > > > > Enrico
>     > > > >
>     > > > >
>     > > > >
>     > > > >
>     > > > >
>     > > > > >
>     > > > > >
>     > > > > > On Fri, May 31, 2019 at 3:02 PM Homer, Tony <[hidden email]>
>     > > > wrote:
>     > > > > > >
>     > > > > > > Currently maven-archetype depends on dom4j 1.6.1 which is
>     > vulnerable
>     > > > to
>     > > > > > CVE-2018-1000632 [1].
>     > > > > > > I filed ARCHETYPE-567 [2] to track this.
>     > > > > > > In order to mitigate this vulnerability, an update to dom4j
>     > 2.1.1 is
>     > > > > > needed.
>     > > > > > > dom4j 2.1.x requires Java 8+ [3].
>     > > > > > > dom4j 2.0.x would retain compatibility with Java 7 (Java 5+) but
>     > the
>     > > > > > latest release (2.0.2) is vulnerable to CVE-2018-1000632.
>     > > > > > > The current dev version (2.0.3) seems to contain a fix for
>     > > > > > CVE-2018-1000632 but has been pending release for ~1 year.
>     > > > > > >
>     > > > > > > I opened PR #28 [4] to make these changes.
>     > > > > > > What else I should do to advance this proposal?
>     > > > > > >
>     > > > > > > Thanks!
>     > > > > > > Tony Homer
>     > > > > > >
>     > > > > > > [1] https://nvd.nist.gov/vuln/detail/CVE-2018-1000632
>     > > > > > > [2] https://issues.apache.org/jira/browse/ARCHETYPE-567
>     > > > > > > [3] https://dom4j.github.io
>     > > > > > > [4] https://github.com/apache/maven-archetype/pull/28
>     > > > > > >
>     > > > > >
>     > > > > >
>     > > > > > --
>     > > > > > Elliotte Rusty Harold
>     > > > > > [hidden email]
>     > > > > >
>     > > > > >
>     > ---------------------------------------------------------------------
>     > > > > > To unsubscribe, e-mail: [hidden email]
>     > > > > > For additional commands, e-mail: [hidden email]
>     > > > > >
>     > > > > >
>     > > >
>     > > >
>     > > >
>     > > > --
>     > > > Elliotte Rusty Harold
>     > > > [hidden email]
>     > > >
>     > > > ---------------------------------------------------------------------
>     > > > To unsubscribe, e-mail: [hidden email]
>     > > > For additional commands, e-mail: [hidden email]
>     > > >
>     > > >
>     >
>     >
>     >
>     > --
>     > Elliotte Rusty Harold
>     > [hidden email]
>     >
>     > ---------------------------------------------------------------------
>     > To unsubscribe, e-mail: [hidden email]
>     > For additional commands, e-mail: [hidden email]
>     >
>     >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



--
Elliotte Rusty Harold
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: proposal for maven-archetype to switch to dom4j 2.1.1 (and Java 8)

Tibor Digana
 @Mickael Istria
@Eric Lilja <[hidden email]>
@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 <[hidden email]> 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 <[hidden email]> 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.
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: proposal for maven-archetype to switch to dom4j 2.1.1 (and Java 8)

Mickael Istria-2
On Monday, June 3, 2019, Tibor Digana <[hidden email]> wrote:
>
> We are the maintainers.


Beware this kind of statements hurt the project and its community.


> Do you inherit from this project and you need dom4j as transitive
> dependency?


More or less yes. M2E embeds maven-archiver and transitive dependencies. We
don't want m2e to tweak the dependencies and we want m2e to not ship CVEs.
So we think.it's better to fix CVEs upstream and we imagined Maven would be
glad welcoming CVE fix contribution like people expect from any serious
project.

>

--
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
Reply | Threaded
Open this post in threaded view
|

Re: proposal for maven-archetype to switch to dom4j 2.1.1 (and Java 8)

Enrico Olivelli
In reply to this post by Tibor Digana
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 <[hidden email]> 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 <[hidden email]
> >
> 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 <[hidden email]>
> > 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" <[hidden email]> wrote:
> > >
> > >      @Mickael Istria
> > >     @Eric Lilja <[hidden email]>
> > >     @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 <[hidden email]>
> > > 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 <
> [hidden email]>
> > > 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.
> > >     > >
> > >     >
> > >
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: proposal for maven-archetype to switch to dom4j 2.1.1 (and Java 8)

Elliotte Rusty Harold
In reply to this post by Tibor Digana
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> > 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" <[hidden email]> wrote:
> > >
> > >      @Mickael Istria
> > >     @Eric Lilja <[hidden email]>
> > >     @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 <[hidden email]>
> > > 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 <[hidden email]>
> > > 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
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: proposal for maven-archetype to switch to dom4j 2.1.1 (and Java 8)

Tamás Cservenák
In reply to this post by Elliotte Rusty Harold
Mkay...
but in general, the (any) plugin dependency would load at "build time"
(java8) to produce code that would run at "runtime" (java7).
Or why would you need to load a plugin dependency in runtime/target JVM?

T


On Tue, Jun 4, 2019 at 7:17 PM Elliotte Rusty Harold <[hidden email]>
wrote:

> Java 8 uses a different major version number in the .class file than
> Java 7. Generally a Java 8 .class file can't be loaded into a Java 7
> VM. In this case, I think dom4j would have to compile for Java 7 for
> the dom4j.jar to load into Java 7.
>
> On Tue, Jun 4, 2019 at 12:32 PM Tamás Cservenák <[hidden email]>
> wrote:
> >
> > Just wondering: what stops you developing on more modern java, and
> > targeting older java? Or in other words, why is using target java a must
> on
> > development? Just curious.
> >
> > Ps: sry for jumping the thread
> >
> > On Mon, Jun 3, 2019, 16:48 Elliotte Rusty Harold <[hidden email]>
> wrote:
> >
> > > I know there are plenty of places at Java 8+. There are also many who
> > > haven't gotten that far. Some of my day job involves Java 7+ clients,
> > > and I know of others even further back than that.
> > >
> > > On Mon, Jun 3, 2019 at 10:38 AM Gary Gregory <[hidden email]>
> > > wrote:
> > > >
> > > > FWIW, we are talking at work about Java 8 and 11 only these days.
> Java 7
> > > is
> > > > in the distant past. Most people can't even get Java 7 updates since
> it
> > > is
> > > > EOL unless you pay.
> > > >
> > > > Gary
> > > >
> > > > On Mon, Jun 3, 2019 at 10:35 AM Elliotte Rusty Harold <
> > > [hidden email]>
> > > > wrote:
> > > >
> > > > > I agree that this should be fixed. I'm not yet convinced that
> > > > > requiring Java 8 and upgrading to dom4j 2.1 is the bets fix.
> > > > >
> > > > > On Mon, Jun 3, 2019 at 10:24 AM Enrico Olivelli <
> [hidden email]>
> > > > > wrote:
> > > > > >
> > > > > > Elliotte,
> > > > > >
> > > > > > Il giorno lun 3 giu 2019 alle ore 15:59 Elliotte Rusty Harold <
> > > > > > [hidden email]> ha scritto:
> > > > > >
> > > > > > > Perhaps ask the dom4j developers first to see if a 2.0.3
> release
> > > can
> > > > > > > be scheduled.
> > > > > > >
> > > > > > > And if that doesn't work, how much effort is it to switch off
> of
> > > dom4j
> > > > > > > completely?
> > > > > > >
> > > > > > > maven-archetype strikes me as too important to drop Java 7
> > > > > > > compatibility this soon.
> > > > > > >
> > > > > >
> > > > > > Are you -1 with this change ?
> > > > > > If an user wan't to use java 7 he can use current version of the
> > > plugin.
> > > > > >
> > > > > > Enrico
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, May 31, 2019 at 3:02 PM Homer, Tony <
> [hidden email]>
> > > > > wrote:
> > > > > > > >
> > > > > > > > Currently maven-archetype depends on dom4j 1.6.1 which is
> > > vulnerable
> > > > > to
> > > > > > > CVE-2018-1000632 [1].
> > > > > > > > I filed ARCHETYPE-567 [2] to track this.
> > > > > > > > In order to mitigate this vulnerability, an update to dom4j
> > > 2.1.1 is
> > > > > > > needed.
> > > > > > > > dom4j 2.1.x requires Java 8+ [3].
> > > > > > > > dom4j 2.0.x would retain compatibility with Java 7 (Java 5+)
> but
> > > the
> > > > > > > latest release (2.0.2) is vulnerable to CVE-2018-1000632.
> > > > > > > > The current dev version (2.0.3) seems to contain a fix for
> > > > > > > CVE-2018-1000632 but has been pending release for ~1 year.
> > > > > > > >
> > > > > > > > I opened PR #28 [4] to make these changes.
> > > > > > > > What else I should do to advance this proposal?
> > > > > > > >
> > > > > > > > Thanks!
> > > > > > > > Tony Homer
> > > > > > > >
> > > > > > > > [1] https://nvd.nist.gov/vuln/detail/CVE-2018-1000632
> > > > > > > > [2] https://issues.apache.org/jira/browse/ARCHETYPE-567
> > > > > > > > [3] https://dom4j.github.io
> > > > > > > > [4] https://github.com/apache/maven-archetype/pull/28
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Elliotte Rusty Harold
> > > > > > > [hidden email]
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: [hidden email]
> > > > > > > For additional commands, e-mail: [hidden email]
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Elliotte Rusty Harold
> > > > > [hidden email]
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Elliotte Rusty Harold
> > > [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
>
>
>
> --
> Elliotte Rusty Harold
> [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: proposal for maven-archetype to switch to dom4j 2.1.1 (and Java 8)

rfscholte
In reply to this post by Elliotte Rusty Harold
> What stops us developing on Java 8?
> Maven project stops us.

I think this deserves some clearance, because I have a different opinion on this.
It is quite natural that plugins start picking up and requiring a more recent version of Java before Maven does.
If there's a good reason to move forward (in this case to Java 8), I don't mind doing that.
With our plugin system, if they can't use this because they run Maven on an older version of Java, they can lock the plugin version to the last compatible one.
Right now most environments are already running on Java 8 and won't notice such upgrade.
Also keep in mind there's a difference between Java for Maven runtime and JDK for the compiler, these can be separated.
I would love to hear from somebody that thinks he or she would be blocked by such change, it shouldn't be an issue but maybe I'm missing a detail.

So if we can stay Java 7 compatible, that's fine but is not a blocking requirement (especially since this plugin is not a lifecycle plugin). 

Robert
On 4-6-2019 22:05:33, Tibor Digana <[hidden email]> wrote:
What stops us developing on Java 8?
Maven project stops us.
We wanted to use Java 7 and not higher. Therefore reworking the little code
with removed dom4j keeps javac still on java7 and we would not have a
problem when dom4j moves to java9+ because of non-applicable CVEs. We can
use Java XML Api instead of dom4j.

On Tue, Jun 4, 2019 at 6:32 PM Tamás Cservenák wrote:

> Just wondering: what stops you developing on more modern java, and
> targeting older java? Or in other words, why is using target java a must on
> development? Just curious.
>
> Ps: sry for jumping the thread
>
> On Mon, Jun 3, 2019, 16:48 Elliotte Rusty Harold
> wrote:
>
> > I know there are plenty of places at Java 8+. There are also many who
> > haven't gotten that far. Some of my day job involves Java 7+ clients,
> > and I know of others even further back than that.
> >
> > On Mon, Jun 3, 2019 at 10:38 AM Gary Gregory
> > wrote:
> > >
> > > FWIW, we are talking at work about Java 8 and 11 only these days. Java
> 7
> > is
> > > in the distant past. Most people can't even get Java 7 updates since it
> > is
> > > EOL unless you pay.
> > >
> > > Gary
> > >
> > > On Mon, Jun 3, 2019 at 10:35 AM Elliotte Rusty Harold
> > [hidden email]>
> > > wrote:
> > >
> > > > I agree that this should be fixed. I'm not yet convinced that
> > > > requiring Java 8 and upgrading to dom4j 2.1 is the bets fix.
> > > >
> > > > On Mon, Jun 3, 2019 at 10:24 AM Enrico Olivelli
> >
> > > > wrote:
> > > > >
> > > > > Elliotte,
> > > > >
> > > > > Il giorno lun 3 giu 2019 alle ore 15:59 Elliotte Rusty Harold
> > > > > [hidden email]> ha scritto:
> > > > >
> > > > > > Perhaps ask the dom4j developers first to see if a 2.0.3 release
> > can
> > > > > > be scheduled.
> > > > > >
> > > > > > And if that doesn't work, how much effort is it to switch off of
> > dom4j
> > > > > > completely?
> > > > > >
> > > > > > maven-archetype strikes me as too important to drop Java 7
> > > > > > compatibility this soon.
> > > > > >
> > > > >
> > > > > Are you -1 with this change ?
> > > > > If an user wan't to use java 7 he can use current version of the
> > plugin.
> > > > >
> > > > > Enrico
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, May 31, 2019 at 3:02 PM Homer, Tony
> [hidden email]>
> > > > wrote:
> > > > > > >
> > > > > > > Currently maven-archetype depends on dom4j 1.6.1 which is
> > vulnerable
> > > > to
> > > > > > CVE-2018-1000632 [1].
> > > > > > > I filed ARCHETYPE-567 [2] to track this.
> > > > > > > In order to mitigate this vulnerability, an update to dom4j
> > 2.1.1 is
> > > > > > needed.
> > > > > > > dom4j 2.1.x requires Java 8+ [3].
> > > > > > > dom4j 2.0.x would retain compatibility with Java 7 (Java 5+)
> but
> > the
> > > > > > latest release (2.0.2) is vulnerable to CVE-2018-1000632.
> > > > > > > The current dev version (2.0.3) seems to contain a fix for
> > > > > > CVE-2018-1000632 but has been pending release for ~1 year.
> > > > > > >
> > > > > > > I opened PR #28 [4] to make these changes.
> > > > > > > What else I should do to advance this proposal?
> > > > > > >
> > > > > > > Thanks!
> > > > > > > Tony Homer
> > > > > > >
> > > > > > > [1] https://nvd.nist.gov/vuln/detail/CVE-2018-1000632
> > > > > > > [2] https://issues.apache.org/jira/browse/ARCHETYPE-567
> > > > > > > [3] https://dom4j.github.io
> > > > > > > [4] https://github.com/apache/maven-archetype/pull/28
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Elliotte Rusty Harold
> > > > > > [hidden email]
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: [hidden email]
> > > > > > For additional commands, e-mail: [hidden email]
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Elliotte Rusty Harold
> > > > [hidden email]
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> >
> >
> >
> > --
> > Elliotte Rusty Harold
> > [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: proposal for maven-archetype to switch to dom4j 2.1.1 (and Java 8)

Homer, Tony
Tibor completed the work of removing dom4j library and reverted the change that moves maven-archetype to Java 8 [1].
This change mitigates the vulnerability to CVE-2018-1000632 while retaining Java 7 compatibility.
In the JIRA I asked about when this can be released and Tibor suggested that I ask the ML.
It seemed best to keep the discussion in the original thread for context, although the subject is no longer accurate!

Can maven-archetype 3.1.1 be released ASAP so that this fix is made public?
My interest (as described earlier in this thread) is to get the CVE mitigation into m2e so that I can stop using a fork in my eclipse product, but it is worthwhile for anyone who has a company policy that is aggressive about CVEs.
Please let me know if there is anything I can do to help with this.

[1] https://issues.apache.org/jira/browse/ARCHETYPE-568

Thanks!
Tony Homer

On 6/5/19 , 5:52 AM, "Tibor Digana" <[hidden email]> wrote:

    I am working on a removal of dom4j library and use of Java XML API.
    Sytwester, connect to the Slack pls.
   
    On Wed, Jun 5, 2019 at 8:28 AM Robert Scholte <[hidden email]> wrote:
   
    > > What stops us developing on Java 8?
    > > Maven project stops us.
    >
    > I think this deserves some clearance, because I have a different opinion
    > on this.
    > It is quite natural that plugins start picking up and requiring a more
    > recent version of Java before Maven does.
    > If there's a good reason to move forward (in this case to Java 8), I don't
    > mind doing that.
    > With our plugin system, if they can't use this because they run Maven on
    > an older version of Java, they can lock the plugin version to the last
    > compatible one.
    > Right now most environments are already running on Java 8 and won't notice
    > such upgrade.
    > Also keep in mind there's a difference between Java for Maven runtime and
    > JDK for the compiler, these can be separated.
    > I would love to hear from somebody that thinks he or she would be blocked
    > by such change, it shouldn't be an issue but maybe I'm missing a detail.
    >
    > So if we can stay Java 7 compatible, that's fine but is not a blocking
    > requirement (especially since this plugin is not a lifecycle plugin).
   


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]