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" <[email protected]> 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 <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
