Re: Backporting 3.8.1 security fix in 3.6.x

@Hervé BOUTEMY I'm fine with any *solution* to this issue which must enable user to use a 3.6.n, n > 3 to block http (and not https) repos by config. I proposed to backport the 3.8 solution (even if not satisfying for some) to avoid to break between 3.6 and 3.8 and later 4.x but while goal is

Re: Backporting 3.8.1 security fix in 3.6.x

disagree: it is my last sentence on the question, no more time to loose non breaking by default is not fixing: fixing is breaking by default and of course, yes, a user can override default secure configuration to allow insecure exceptions or even global insecure: it's his responsibility done

Re: Backporting 3.8.1 security fix in 3.6.x

Le ven. 2 avr. 2021 à 18:39, Hervé BOUTEMY a écrit : > backporting MNG-7119, I understand that it fixes a (low severity) security > issue > > backporting MNG-7116, MNG-7117 and MNG-7128 without MNG-7118 does not > backport > THE security fix = MNG-7118 block HTTP by default > Nop, this is NOT a

Re: Backporting 3.8.1 security fix in 3.6.x

backporting MNG-7119, I understand that it fixes a (low severity) security issue backporting MNG-7116, MNG-7117 and MNG-7128 without MNG-7118 does not backport THE security fix = MNG-7118 block HTTP by default sorry, breaking by default is the security fix: if you don't want breaking by

Security/Versioning policy proposal

Hi all, What about starting from something like http://tomee.apache.org/security/security.html for our versioning policy. Goal is really to let user plan their versioning policy and ensure there is no big surprises in the needed upgrades to have bugfixes. The tomee one spiritI aligns on the

Re: [MJLINK] Create JavaFX application runtime

Glad it helped! I was thinking maybe this should be filed as an issue at the javafx mailing list. On Thu, 1 Apr 2021, 22:59 Abhinay, wrote: > Hi Robert, > > The issue can be reproduced using theJavaFX application hosted on Github >

Re: Backporting 3.8.1 security fix in 3.6.x

Le ven. 2 avr. 2021 à 16:08, Elliotte Rusty Harold a écrit : > On Fri, Apr 2, 2021 at 11:44 AM Romain Manni-Bucau > wrote: > > > So teams pick a version with semver like in mind assuming they will get > > security fixes in this branch for the duration of the projects which tend > > to be wrong

Re: Backporting 3.8.1 security fix in 3.6.x

On Fri, Apr 2, 2021 at 11:44 AM Romain Manni-Bucau wrote: > So teams pick a version with semver like in mind assuming they will get > security fixes in this branch for the duration of the projects which tend > to be wrong since maven tends to update minor as often as patch digit. That is a very

Re: Backporting 3.8.1 security fix in 3.6.x

"we must clarify our versioning policy" Hopefully semver-ish, hopefully not "burning" version numbers when a release candidate fails, that's crazy making for users, especially for a tool as critical as Maven Gary On Fri, Apr 2, 2021, 07:44 Romain Manni-Bucau wrote: > Le ven. 2 avr. 2021 à

[GitHub] [maven-site] mthmulders merged pull request #232: Add 'Introduction to Maven Toolchains' blog

mthmulders merged pull request #232: URL: https://github.com/apache/maven-site/pull/232 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service,

[GitHub] [maven-site] mthmulders opened a new pull request #232: Add 'Introduction to Maven Toolchains' blog

mthmulders opened a new pull request #232: URL: https://github.com/apache/maven-site/pull/232 Add a reference to the blog post 'Introduction to Maven Toolchains' by myself. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub

Re: Backporting 3.8.1 security fix in 3.6.x

Le ven. 2 avr. 2021 à 13:30, Slawomir Jaranowski a écrit : > From a maven user, plugin developer perspective it is not important for me > if I upgrade maven to 3.6.x or 3.8.x if I have changelog for it. > > More important is to know some of the release and support policies. > In other words, to

Re: Backporting 3.8.1 security fix in 3.6.x

>From a maven user, plugin developer perspective it is not important for me if I upgrade maven to 3.6.x or 3.8.x if I have changelog for it. More important is to know some of the release and support policies. In other words, to know which version can contain new features, which only bug fix,

Re: Backporting 3.8.1 security fix in 3.6.x

If you're speaking on behalf of others, please let those people explain their situation. So far I've only heard you, that's not enough for me to support a backport. Robert On 2-4-2021 11:01:12, Romain Manni-Bucau wrote: Le ven. 2 avr. 2021 à 10:44, Robert Scholte a écrit : > I think there are

Re: Backporting 3.8.1 security fix in 3.6.x

Le ven. 2 avr. 2021 à 10:44, Robert Scholte a écrit : > I think there are a couple of issues here: > - To me this shouldn't be done with a PR, but as a set of cherry-picks to > keep to original commit history and references. > Was the way it was created, PR is just to share it there. > -

Re: Backporting 3.8.1 security fix in 3.6.x

I think there are a couple of issues here: - To me this shouldn't be done with a PR, but as a set of cherry-picks to keep to original commit history and references. - Branch 3.6.x contains commits that are unrelated to the 3.8.x branch - I still don't see the need for this backport. I really

OpenJDK 17 Early Access build 16 is now available

Hi Robert , *OpenJDK 17 Early Access build 16 is now available at **http://jdk.java.net/17* * These early-access , open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception

Backporting 3.8.1 security fix in 3.6.x

Hi all, As explained in another thread, I created https://github.com/apache/maven/pull/462 to backport the security fix on 3.8 in 3.6.x. Anyone able to review it? Only change is that the default configuration is not there but it can be enabled - idea is to document it instead of breaking by