Re: [DISCUSS] Major changed for 4.x
Le lun. 28 août 2023 à 08:04, Olivier Lamy a écrit : > Hi, > > On Tue, 22 Aug 2023 at 17:36, Guillaume Nodet wrote: > > > > Hi everyone, > > > > I hope you guys have been able to rest a bit during the summer (for those > > that are back to work already)... > > > > I've pushed a few important PRs in the past months and I'd really like to > > get the discussion going around those. Those are major changes that I > > think we should introduce in Maven 4 asap: > > * Better support for alternative POM syntaxes > > * Needed infrastructure to evolve the model > > * POM mixins > > * Support for XML entities / XInclude > > I really like the idea of being able to improve the model. > For the model, and I think this is the most critical part and should really be discussed further, I've explained in more detail at https://github.com/apache/maven/pull/1160 The major point is how to handle new models in maven central... > I find a bit scary the idea of XML entities/XInclude especially for > all the possible security problems that I can imagine coming with > that. > No real example in mind, but I had so many issues problems in the last > 10 years with XML entities/XInclude :) > but maybe I'm wrong. > how do you exactly plan to do that? > For the XML entities / XInclude, I think the security risks can easily be mitigated. I've just pushed an additional commit which restricts any entity / xinclude loading to only files inside the rootDirectory tree. This is easily achieved as all the loads are done through a single object: https://github.com/apache/maven/pull/1205/commits/89544c9c3c4cedfd3cd5b4fdfd8a84d8f003ef3a#diff-afe459a772f52262ac9aac04cf7822659de5540edd2302722478358146249574R32 I've added a few unit tests to cover this at https://github.com/apache/maven/pull/1205/commits/89544c9c3c4cedfd3cd5b4fdfd8a84d8f003ef3a#diff-2b42337852eda2ae6fd664a97ac2a0deca997ea23debfa0158af89c678d8c6e4R30 Cheers, Guillaume > > > > > The first 3 changes are stacked onto each other. The first one is the > > support for alternative POM syntaxes [2]. Note that no syntax is > provided > > by the PR, but an example extension is provided in the IT PR [3], the > > reader being generated using the maven model and the IT's project is > using > > it [4]. The main idea is to provide an enhanced XML syntax if we want, > as > > it was discussed for the POM 5.0 [5]. > > > > The second one provides the ability to make evolution to the model > without > > breaking the maven ecosystem. The model has been stuck in 4.0.0 version > > for 15 years or so, most of the things that would have required a change > > have been delayed or worked around. The consumer POM that has been > > introduced in Maven 4 is a first step, but I think we should go further. > > Please read the details in the PR [6]. > > > > The third one is the support for POM mixins [7]. That one is still a > > draft. Two ITs have been written to leverage mixins using GAV or as > > relative paths [8]. This definitely needs some work, but the current > state > > definitely shows that it can be implemented and introduced in the next > > alphas. > > > > The last one is a relatively small PR [9] which brings support for XML > > entities and XInclude loaded from external files. All loaded files are > > loaded using relative URLs (absolute URLs are rejected for security > > reasons). The entities and xinclude bits are all inlined during the raw > -> > > consumer POM transformation so that they don't appear in repositories. I > > wrote this PR as a possible alternative for mixins, that's the main > reason > > why I include it in this discussion. > > > > I'm not necessarily looking for in-depth reviews of the PRs, but at least > > to find a consensus and general agreement on the way forward. > > > > Cheers, > > Guillaume > > > > [2] https://github.com/apache/maven/pull/1197 > > [3] > > > https://github.com/apache/maven-integration-testing/pull/276/files#diff-ffb3dec529cab94ebf3c5830444275ad2b2e4826fe1df843454882efadd2446c > > [4] > > > https://github.com/apache/maven-integration-testing/pull/276/files#diff-8d7362e60d231ad8c5d4b7746873da2855d9cf1fd5aeeca9c143ed942bd94b38 > > [5] > > > https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0 > > [6] https://github.com/apache/maven/pull/1160 > > [7] > > > https://github.com/apache/maven/pull/1209/commits/211e27acd21a6cb8cee30ccd066499fc613a5c82 > > [8] > > > https://github.com/apache/maven-integration-testing/tree/b2642d74caae854051dc77acd19b972dfe66b1cd/core-it-suite/src/test/resources/mng-5102-mixins > > [9] https://github.com/apache/maven/pull/1205 > > > > -- > > > > Guillaume Nodet > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Guillaume Nodet
CVE-2021-26291 for plugin writers
Maven 3.8.1 release notes describe CVE-2021-26291 fixed in that version: https://maven.apache.org/docs/3.8.1/release-notes.html That's the best explanation of this CVE of all I saw online. But it misses guide for plugin authors. GitHub's security scanner created this alert for my plugin https://github.com/avodonosov/hashver-maven-plugin/security/dependabot/3 and a corresponding pull request, where it suggest to change dependency maven-core from 3.3.8 to 3.8.1: https://github.com/avodonosov/hashver-maven-plugin/pull/11 I am reluctant to commit this change because I am afraid the plugin may stop working for users of older maven versions. I suppose this CVE is not relevant to plugin authors, my reasoning is in the pull request comments. Am I right that the CVE does not affect the plugin? It would be good if the 3.8.1 release notes were extended with explanations is it safe for plugins to depend on older versions of maven libs. Best regards, - Anton - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How to fix MNG-7855 (dependencies wrongly put on class-path rather than module-path)?
Le 28/08/2023 à 14:24, Martin Desruisseaux a écrit : Rational: a direct dependency may be known to be compatible with both the class-path and module-path (e.g. it may duplicate "module-info" into "META-INF/services/"), but maybe some transitive dependencies are not. Another argument for making it non-transitive: while I'm currently focusing on class-path versus module-path issue, I envision more JPMS-related extensions to the POM model. For example could also contain an element telling to Maven "please emit --add-exports arguments with me as the target for all non-exported packages of the project". That would be useful for testing with JUnit or TestNG in particular. But a project exporting all its packages to JUnit may not want to export those packages to all JUnit dependencies as well. If nevertheless a JUnit transitive dependency needs those exports, the overriding mechanism suggested in previous email would work. Martin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How to fix MNG-7855 (dependencies wrongly put on class-path rather than module-path)?
Le 28/08/2023 à 13:30, Elliotte Rusty Harold a écrit : > On Mon, Aug 28, 2023 at 8:49 AM Martin Desruisseaux wrote: >> * Long term solution would be to change the POM model by expanding the >> section for controlling on an individual basis how to >> handle each dependency. > > How would this work with transitive dependencies? I propose to make it non-transitive: an explicit request to put a dependency on the class-path or module-path would apply only to that direct dependency. The transitive dependencies would continue to be handled as declared in the pom.xml file of the direct dependency. Rational: a direct dependency may be known to be compatible with both the class-path and module-path (e.g. it may duplicate "module-info" into "META-INF/services/"), but maybe some transitive dependencies are not. However developers could override the behavior of a transitive dependency by declaring that dependency explicitly in the project pom.xml. It would be similar to overriding the version of a transitive dependency. > Meta-point: it's easier to keep long term track of discussions like > this if they're in the issue tracker instead of the mailing list. We have https://issues.apache.org/jira/browse/MNG-7855. Should it be a wiki or a GitHub discussion page instead? (whatever is more convenient for developers involved in those parts of Maven). Martin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How to fix MNG-7855 (dependencies wrongly put on class-path rather than module-path)?
On Mon, Aug 28, 2023 at 8:49 AM Martin Desruisseaux wrote: > > Hello again > > What about the following proposal for addressing MNG-7855? > > * Long term solution would be to change the POM model by expanding the > section for controlling on an individual basis how to > handle each dependency. How would this work with transitive dependencies? Meta-point: it's easier to keep long term track of discussions like this if they're in the issue tracker instead of the mailing list. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How to fix MNG-7855 (dependencies wrongly put on class-path rather than module-path)?
Hello again What about the following proposal for addressing MNG-7855? * Long term solution would be to change the POM model by expanding the section for controlling on an individual basis how to handle each dependency. * Short term solution would be to add a configuration element in all Maven plugins executing Java code (maven-surefire-plugin, exec-maven-plugin, other?) for specifying the *default* rule for class-path versus module-path dispatching. That default rule would be used when the section does not specify how to handle a specific dependency. The maven-surefire-plugin already provide the following option: true I propose to deprecate the use of "true" or "false" values and replace them by the following enumeration values: * never — equivalent to the current "false" value: put everything on the class-path, including modularized dependencies. * autoIfModularizedProject — equivalent to the current "true" value. Same as "auto" but enabled only if the project is itself modularized. Provided for compatibility with current behavior, but I would not recommend that mode. * auto — determined automatically from whether the dependency is modularized. This is what the default mode should have been in my opinion. * always — unconditionally put everything on the module-path, even non-modularized dependencies. Yes it works, and sometime is desirable. What would be the process for moving forward? Do I need to write the proposal in some Change Request form? Or do I prepare a pull request directly? In the later case, can someone point me to the Surefire code to edit? Thanks, Martin [1]https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#usemodulepath
