You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2021/04/02 07:20:37 UTC
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 default.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Re: Backporting 3.8.1 security fix in 3.6.x
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@Hervé BOUTEMY <he...@free.fr> 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 reached I'm happy with any solution but have to admit
I'm not sure which one you aim at with your last answer so please advice me
:s.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le ven. 2 avr. 2021 à 19:32, Hervé BOUTEMY <he...@free.fr> a écrit :
> 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 with me
>
> Le vendredi 2 avril 2021, 19:01:49 CEST Romain Manni-Bucau a écrit :
> > Le ven. 2 avr. 2021 à 18:39, Hervé BOUTEMY <he...@free.fr> 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 security fix for most build Hervé, it is only for
> builds
> > not customizing the global settings.xml.
> > Concretely, it is 1-1 due to maven usage to have or not the default
> > regarding the security fix (agree it is saner to have it by default) but
> > for 3.6 branch breaking by default is not an opiotn, therefore enabling
> to
> > use it but not enabling it out of the box.
> >
> > > sorry, breaking by default is the security fix: if you don't want
> breaking
> > > by
> > > default, you don't want the security fix
> >
> > Not sure I'm following the reasoning.
> > What I said in the 3.6/3.8 thread was that we must enable the security
> fix
> > to be used in 3.6 branch, this is what does the PR.
> >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le vendredi 2 avril 2021, 09:20:37 CEST Romain Manni-Bucau a écrit :
> > > > 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 default.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > >
> > > https://github.com/rmannibucau>
> > >
> > > > | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > >
> > > > <
> > >
> > >
> https://www.packtpub.com/application-development/java-ee-8-high-performanc
> > > e
> > >
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Backporting 3.8.1 security fix in 3.6.x
Posted by Hervé BOUTEMY <he...@free.fr>.
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 with me
Le vendredi 2 avril 2021, 19:01:49 CEST Romain Manni-Bucau a écrit :
> Le ven. 2 avr. 2021 à 18:39, Hervé BOUTEMY <he...@free.fr> 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 security fix for most build Hervé, it is only for builds
> not customizing the global settings.xml.
> Concretely, it is 1-1 due to maven usage to have or not the default
> regarding the security fix (agree it is saner to have it by default) but
> for 3.6 branch breaking by default is not an opiotn, therefore enabling to
> use it but not enabling it out of the box.
>
> > sorry, breaking by default is the security fix: if you don't want breaking
> > by
> > default, you don't want the security fix
>
> Not sure I'm following the reasoning.
> What I said in the 3.6/3.8 thread was that we must enable the security fix
> to be used in 3.6 branch, this is what does the PR.
>
> > Regards,
> >
> > Hervé
> >
> > Le vendredi 2 avril 2021, 09:20:37 CEST Romain Manni-Bucau a écrit :
> > > 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 default.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> >
> > https://github.com/rmannibucau>
> >
> > > | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > >
> > > <
> >
> > https://www.packtpub.com/application-development/java-ee-8-high-performanc
> > e
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Backporting 3.8.1 security fix in 3.6.x
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le ven. 2 avr. 2021 à 18:39, Hervé BOUTEMY <he...@free.fr> 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 security fix for most build Hervé, it is only for builds
not customizing the global settings.xml.
Concretely, it is 1-1 due to maven usage to have or not the default
regarding the security fix (agree it is saner to have it by default) but
for 3.6 branch breaking by default is not an opiotn, therefore enabling to
use it but not enabling it out of the box.
>
> sorry, breaking by default is the security fix: if you don't want breaking
> by
> default, you don't want the security fix
>
Not sure I'm following the reasoning.
What I said in the 3.6/3.8 thread was that we must enable the security fix
to be used in 3.6 branch, this is what does the PR.
>
> Regards,
>
> Hervé
>
> Le vendredi 2 avril 2021, 09:20:37 CEST Romain Manni-Bucau a écrit :
> > 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 default.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau>
> > | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Backporting 3.8.1 security fix in 3.6.x
Posted by Hervé BOUTEMY <he...@free.fr>.
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
default, you don't want the security fix
Regards,
Hervé
Le vendredi 2 avril 2021, 09:20:37 CEST Romain Manni-Bucau a écrit :
> 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 default.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau>
> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Backporting 3.8.1 security fix in 3.6.x
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le ven. 2 avr. 2021 à 16:08, Elliotte Rusty Harold <el...@ibiblio.org> a
écrit :
> On Fri, Apr 2, 2021 at 11:44 AM Romain Manni-Bucau
> <rm...@gmail.com> 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 unjustified assumption. A miniscule fraction of open
> source projects issue patch releases for anything but head. The Linux
> kernel comes to mind. I can't think of a second, and none from the
> Apache Project. I'm sure they're out there, but it's certainly less
> than 1%. Absent an explicit statement that a minor version will
> receive security fixes in the future, I would never assume that
> anything other than the latest release is likely to be patched.
>
Agree with that, this is why we have a "defining a release policy before
next release" track right now but in the mean time, since several apache
project defined such policy (thinking to karaf and tomee) and that maven
is really really mainstream, we can't ignore it had been done today - and
once again it is why we get so much negative feedback each time we jump
versions.
So let's fix the immediate need and accomodate our users and fix the real
issue right after/soon to avoid it happens again.
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Backporting 3.8.1 security fix in 3.6.x
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Fri, Apr 2, 2021 at 11:44 AM Romain Manni-Bucau
<rm...@gmail.com> 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 unjustified assumption. A miniscule fraction of open
source projects issue patch releases for anything but head. The Linux
kernel comes to mind. I can't think of a second, and none from the
Apache Project. I'm sure they're out there, but it's certainly less
than 1%. Absent an explicit statement that a minor version will
receive security fixes in the future, I would never assume that
anything other than the latest release is likely to be patched.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Backporting 3.8.1 security fix in 3.6.x
Posted by Gary Gregory <ga...@gmail.com>.
"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 <rm...@gmail.com> wrote:
> Le ven. 2 avr. 2021 à 13:30, Slawomir Jaranowski <s....@gmail.com>
> 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 know which version can contain new features, which
> only
> > bug fix, security updates and which version is not maintained any more.
> >
> > I see that without such a policy you don't agree with yourself.
> > As many ideas as many people for a version number ...
> >
>
> Exactly, it is what I tried to write in the next release version thread.
> It is fine to do jumps and not respect maintenance branches for end users
> while documented upfront but not after.
> As of today maven has no versioning policy and tend to communicate over
> something close to semver on the list - which is not respected in practise
> sadly.
> 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.
> So overall for this time we should just let a 3.6.4 go out to mitigate the
> side effect of this issue but after *and before any other release* we must
> clarify our versioning policy - minimum being what about security fixes
> (even if we say we only rely on major).
>
>
> >
> > pt., 2 kwi 2021 o 12:44 Robert Scholte <rf...@apache.org>
> napisał(a):
> >
> > > 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 <rm...@gmail.com>
> wrote:
> > > 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.
> > >
> > >
> > > > - Branch 3.6.x contains commits that are unrelated to the 3.8.x
> branch
> > > >
> > >
> > > Not sure what you have in mind behind that except that if so 3.8 can
> need
> > > to be updated - but not sure I got it right.
> > >
> > >
> > > > - I still don't see the need for this backport. I really doubt that
> > > people
> > > > would pick the possible 3.6.4 over 3.8.1 if they want to protect
> > > themselves
> > > > and do the configuration themselves. As you keep pushing for such a
> > > > release, please let the community comment (including why they need it
> > and
> > > > why using 3.8.1 is not an option) on MNG-7134[1] first.
> > > >
> > >
> > > I don't doubt about it, I have some contacts needing to stick to 3.6 +
> be
> > > CVE free at the same time for at least the coming 2 years, just trying
> to
> > > make these users happy.
> > > I already explained in previous posts why it was saner to do it on
> maven
> > > side (to avoid forks mainly which can lead to different "fixes" and
> > > behaviors - already saw it by the past + keep the common maven tooling
> as
> > > sdkman and ides plain support).
> > >
> > >
> > > >
> > > > Robert
> > > >
> > > > [1] https://issues.apache.org/jira/browse/MNG-7134
> > > > On 2-4-2021 09:21:04, Romain Manni-Bucau wrote:
> > > > 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 default.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau | Blog
> > > > | Old Blog
> > > > | Github |
> > > > LinkedIn | Book
> > > >
> > > >
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >
>
Re: Backporting 3.8.1 security fix in 3.6.x
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le ven. 2 avr. 2021 à 13:30, Slawomir Jaranowski <s....@gmail.com> 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 know which version can contain new features, which only
> bug fix, security updates and which version is not maintained any more.
>
> I see that without such a policy you don't agree with yourself.
> As many ideas as many people for a version number ...
>
Exactly, it is what I tried to write in the next release version thread.
It is fine to do jumps and not respect maintenance branches for end users
while documented upfront but not after.
As of today maven has no versioning policy and tend to communicate over
something close to semver on the list - which is not respected in practise
sadly.
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.
So overall for this time we should just let a 3.6.4 go out to mitigate the
side effect of this issue but after *and before any other release* we must
clarify our versioning policy - minimum being what about security fixes
(even if we say we only rely on major).
>
> pt., 2 kwi 2021 o 12:44 Robert Scholte <rf...@apache.org> napisał(a):
>
> > 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 <rm...@gmail.com> wrote:
> > 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.
> >
> >
> > > - Branch 3.6.x contains commits that are unrelated to the 3.8.x branch
> > >
> >
> > Not sure what you have in mind behind that except that if so 3.8 can need
> > to be updated - but not sure I got it right.
> >
> >
> > > - I still don't see the need for this backport. I really doubt that
> > people
> > > would pick the possible 3.6.4 over 3.8.1 if they want to protect
> > themselves
> > > and do the configuration themselves. As you keep pushing for such a
> > > release, please let the community comment (including why they need it
> and
> > > why using 3.8.1 is not an option) on MNG-7134[1] first.
> > >
> >
> > I don't doubt about it, I have some contacts needing to stick to 3.6 + be
> > CVE free at the same time for at least the coming 2 years, just trying to
> > make these users happy.
> > I already explained in previous posts why it was saner to do it on maven
> > side (to avoid forks mainly which can lead to different "fixes" and
> > behaviors - already saw it by the past + keep the common maven tooling as
> > sdkman and ides plain support).
> >
> >
> > >
> > > Robert
> > >
> > > [1] https://issues.apache.org/jira/browse/MNG-7134
> > > On 2-4-2021 09:21:04, Romain Manni-Bucau wrote:
> > > 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 default.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau | Blog
> > > | Old Blog
> > > | Github |
> > > LinkedIn | Book
> > >
> > >
> >
>
>
> --
> Sławomir Jaranowski
>
Re: Backporting 3.8.1 security fix in 3.6.x
Posted by Slawomir Jaranowski <s....@gmail.com>.
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, security updates and which version is not maintained any more.
I see that without such a policy you don't agree with yourself.
As many ideas as many people for a version number ...
pt., 2 kwi 2021 o 12:44 Robert Scholte <rf...@apache.org> napisał(a):
> 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 <rm...@gmail.com> wrote:
> 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.
>
>
> > - Branch 3.6.x contains commits that are unrelated to the 3.8.x branch
> >
>
> Not sure what you have in mind behind that except that if so 3.8 can need
> to be updated - but not sure I got it right.
>
>
> > - I still don't see the need for this backport. I really doubt that
> people
> > would pick the possible 3.6.4 over 3.8.1 if they want to protect
> themselves
> > and do the configuration themselves. As you keep pushing for such a
> > release, please let the community comment (including why they need it and
> > why using 3.8.1 is not an option) on MNG-7134[1] first.
> >
>
> I don't doubt about it, I have some contacts needing to stick to 3.6 + be
> CVE free at the same time for at least the coming 2 years, just trying to
> make these users happy.
> I already explained in previous posts why it was saner to do it on maven
> side (to avoid forks mainly which can lead to different "fixes" and
> behaviors - already saw it by the past + keep the common maven tooling as
> sdkman and ides plain support).
>
>
> >
> > Robert
> >
> > [1] https://issues.apache.org/jira/browse/MNG-7134
> > On 2-4-2021 09:21:04, Romain Manni-Bucau wrote:
> > 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 default.
> >
> > Romain Manni-Bucau
> > @rmannibucau | Blog
> > | Old Blog
> > | Github |
> > LinkedIn | Book
> >
> >
>
--
Sławomir Jaranowski
Re: Backporting 3.8.1 security fix in 3.6.x
Posted by Robert Scholte <rf...@apache.org>.
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 <rm...@gmail.com> wrote:
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.
> - Branch 3.6.x contains commits that are unrelated to the 3.8.x branch
>
Not sure what you have in mind behind that except that if so 3.8 can need
to be updated - but not sure I got it right.
> - I still don't see the need for this backport. I really doubt that people
> would pick the possible 3.6.4 over 3.8.1 if they want to protect themselves
> and do the configuration themselves. As you keep pushing for such a
> release, please let the community comment (including why they need it and
> why using 3.8.1 is not an option) on MNG-7134[1] first.
>
I don't doubt about it, I have some contacts needing to stick to 3.6 + be
CVE free at the same time for at least the coming 2 years, just trying to
make these users happy.
I already explained in previous posts why it was saner to do it on maven
side (to avoid forks mainly which can lead to different "fixes" and
behaviors - already saw it by the past + keep the common maven tooling as
sdkman and ides plain support).
>
> Robert
>
> [1] https://issues.apache.org/jira/browse/MNG-7134
> On 2-4-2021 09:21:04, Romain Manni-Bucau wrote:
> 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 default.
>
> Romain Manni-Bucau
> @rmannibucau | Blog
> | Old Blog
> | Github |
> LinkedIn | Book
>
>
Re: Backporting 3.8.1 security fix in 3.6.x
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le ven. 2 avr. 2021 à 10:44, Robert Scholte <rf...@apache.org> 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.
> - Branch 3.6.x contains commits that are unrelated to the 3.8.x branch
>
Not sure what you have in mind behind that except that if so 3.8 can need
to be updated - but not sure I got it right.
> - I still don't see the need for this backport. I really doubt that people
> would pick the possible 3.6.4 over 3.8.1 if they want to protect themselves
> and do the configuration themselves. As you keep pushing for such a
> release, please let the community comment (including why they need it and
> why using 3.8.1 is not an option) on MNG-7134[1] first.
>
I don't doubt about it, I have some contacts needing to stick to 3.6 + be
CVE free at the same time for at least the coming 2 years, just trying to
make these users happy.
I already explained in previous posts why it was saner to do it on maven
side (to avoid forks mainly which can lead to different "fixes" and
behaviors - already saw it by the past + keep the common maven tooling as
sdkman and ides plain support).
>
> Robert
>
> [1] https://issues.apache.org/jira/browse/MNG-7134
> On 2-4-2021 09:21:04, Romain Manni-Bucau <rm...@gmail.com> wrote:
> 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 default.
>
> Romain Manni-Bucau
> @rmannibucau | Blog
> | Old Blog
> | Github |
> LinkedIn | Book
>
>
Re: Backporting 3.8.1 security fix in 3.6.x
Posted by Robert Scholte <rf...@apache.org>.
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 doubt that people would pick the possible 3.6.4 over 3.8.1 if they want to protect themselves and do the configuration themselves. As you keep pushing for such a release, please let the community comment (including why they need it and why using 3.8.1 is not an option) on MNG-7134[1] first.
Robert
[1] https://issues.apache.org/jira/browse/MNG-7134
On 2-4-2021 09:21:04, Romain Manni-Bucau <rm...@gmail.com> wrote:
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 default.
Romain Manni-Bucau
@rmannibucau | Blog
| Old Blog
| Github |
LinkedIn | Book