[
https://issues.apache.org/jira/browse/MNG-8569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17926117#comment-17926117
]
Guillaume Nodet commented on MNG-8569:
--------------------------------------
{quote}I don't understand. If the range is closed and we're selecting the
lowest version, then [2.1,3]still selects 2.1, no matter which versions have
been released. What am I missing?
{quote}
If another dependency depends on the same artifact with a 2.2 version, the
conflict resolution will select 2.2 for the whole tree.
{quote}And, yes, restricting the range to a list of compatible versions is a
valid use case. Unfortunately it's very insecure so developers need to stop
doing it.{quote}
Not if you refer to released version. If you know {{3.0}} is incompatible
(which means it has been released), you can use a range {{[2.1,3)}} quite
safely. Unless you don't trust any release, but then, you need to use closed
ranges such as {{[2.1]}} everywhere.
> 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)
