Re: Backporting 3.8.1 security fix in 3.6.x

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Backporting 3.8.1 security fix in 3.6.x

rfscholte
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Backporting 3.8.1 security fix in 3.6.x

Gary Gregory-2
"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 <[hidden email]> wrote:

> Le ven. 2 avr. 2021 à 13:30, Slawomir Jaranowski <[hidden email]>
> 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 <[hidden email]>
> 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 <[hidden email]>
> 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
> >
>