@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 reac
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 w
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
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
defaul
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 s
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
"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 à 13:3
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 k
>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, secur
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
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.
> - Branc
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
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 defau
13 matches
Mail list logo
