[
https://issues.apache.org/jira/browse/MNG-8569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17930456#comment-17930456
]
Guillaume Nodet edited comment on MNG-8569 at 3/7/25 9:43 AM:
--------------------------------------------------------------
Yes, I'm suggesting to change the behavior or ranges, but there's no equivalent
right now.
I think there are two main cases for using a range as I explained:
* you want to use the latest version, but you're lazy and don't want to change
your POM when you release a new parent or dependency and you want the upgrade
to be done without having to change the pom
* you want to restrict the possible version used for some other reasons
The first use case is what we want to avoid, it makes build not reproducible,
etc...
I think the second one is legit and should be preserved.
There are 3 things when using a range:
* the selected version must belong to the range
* the selected version is subject to version conflict resolution
* the version selected is the highest from the range
When you specify {{[2.1,3)}}, the resolver will list repositories to find the
_highest_ version in that range, and pick it. When you write your POM, maybe
there are {{2.1}} and {{2.2}}, but as you suggest, anyone could release
{{2.99}} and it would be picked up _automatically_.
I'm proposing to remove this very behavior of checking remote repos for the
highest version. The behavior would be to just use {{2.1}} as usual, but with
the additional constraint that conflict resolution can not end up selecting
version {{3.0}} as it's outside the range.
An extended syntax could support selecting a different (but always explicit)
version by default, maybe something like {{2.2;[2.1,3.0)}} which would mean:
version is by default {{2.2}}, unless a conflict resolution changes that, but
restrict the version to {{[2.1,3.0)}} range.
was (Author: gnt):
Yes, I'm suggesting to change the behavior or ranges, but there's no equivalent
right now.
I think there are two main cases for using a range as I explained:
* you want to use the latest version, but you're lazy and don't want to change
your POM when you release a new parent or dependency and you want the upgrade
to be done without having to change the pom
* you want to restrict the possible version used for some other reasons
The first use case is what we want to avoid, it makes build not reproducible,
etc...
I think the second one is legit and should be preserved.
There are two things when using a range:
* the selected version must belong to the range
* the selected version is subject to version conflict resolution
* the version selected is the highest from the range
When you specify {{[2.1,3)}}, the resolver will list repositories to find the
_highest_ version in that range, and pick it. When you write your POM, maybe
there are {{2.1}} and {{2.2}}, but as you suggest, anyone could release
{{2.99}} and it would be picked up _automatically_.
I'm proposing to remove this very behavior of checking remote repos for the
highest version. The behavior would be to just use {{2.1}} as usual, but with
the additional constraint that conflict resolution can not end up selecting
version {{3.0}} as it's outside the range.
An extended syntax could support selecting a different (but always explicit)
version by default, maybe something like {{2.2;[2.1,3.0)}} which would mean:
version is by default {{2.2}}, unless a conflict resolution changes that, but
restrict the version to {{[2.1,3.0)}} range.
> Deprecate and remove version ranges
> -----------------------------------
>
> Key: MNG-8569
> URL: https://issues.apache.org/jira/browse/MNG-8569
> Project: Maven
> Issue Type: Improvement
> Reporter: Elliotte Rusty Harold
> Priority: Critical
>
> To protect Maven users, we should eliminate, or at the very least warn, when
> version ranges are used in dependency elements. See
> [https://jlbp.dev/JLBP-14] for the rationale. tldr; version ranges make
> projects vulnerable to malicious changes of ownership in dependencies that
> can lead to remotely exploitable arbitrary code execution. I'd rate this
> about a 9.0 on the severity scale.
> I don't know of an attack using this vector in Java (yet) but it has
> been used multiple times in other ecosystems to steal bitcoins and
> install malware. Java has been lucky so far, but we are by no means
> immune to it.
> Since this is a compatibility breaking change, which I don't take likely but
> IMHO is worth it in this case, use a multi-step process:
> # Discourage this in the docs for version ranges, especially the POM
> reference.
> # Warn about this in the build when version ranges are encountered.
> # Formally deprecate the relevant code in the repo. (Might not be necessary.)
> # Add a switch (system property) to disable version ranges. Switch is off by
> default.
> # Turn the switch on by default.
> # Remove the switch.
> This might take a few years, so let's start now. It's also possible an active
> attack will push us to do this overnight. If we start now, maybe we'll be
> lucky enough to avoid emergency responses in the future.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
