[
https://issues.apache.org/jira/browse/MNG-8569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17929743#comment-17929743
]
Guillaume Nodet commented on MNG-8569:
--------------------------------------
> No, {{[2.1,3) }}is not safe. 2.99.82 can still be released and override what
> the developer though they were getting. It's not quite that we don't trust
> any release. It's that we don't trust any future release that might come from
> a different developer or have unannounced and unreviewed changes. So yes,
> developers should use specific versions everywhere. Failing to do that opens
> a major security hole.
You missed the point where I said that {{[2.1,3)}} would behave as {{2.1}} for
the default version selection, i.e. select 2.1 by default instead of the
highest. But still forbid the use of any version >= 3.
We just can't expect {{2.1}} to force the use of that explicit version always.
This would require the user to align all version in the dependency tree, which
is not possible when you don't control the whole tree.
So {{[2.1,3)}} is not unsafe if the highest version is not automatically picked
up. What's unsafe is if Maven somehow gets the highest version, in which case,
someone could produce a 2.99.82 which would be used automatically. But if
Maven picks the lowest version, {{2.1}} would be exactly the same as
{{[2.1,)}}, in which case {{[2.1,3)}} would simply means: _use version 2.1, but
if any other dependency requires a higher version, use that one, but do not go
up to 3.0_. The use case would be if you know that 3.0 brought an incompatible
change and your jar cannot use it.
> 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)
