[
https://issues.apache.org/jira/browse/MNG-8569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17938840#comment-17938840
]
Arkadiusz Biczewski commented on MNG-8569:
------------------------------------------
I am strongly against removing version ranges from maven as this is really
useful feature to have well defined continous builds. We use version range in
developemnt phase to consume latest builds prepared by other team (which are
numbered like 2.3.0.x, where x is the build number for given release, which is
used instead of a snapshot for easier identification of used version), but when
generating our artifact out of the project, we make use of
versions:resolve-ranges -Dincludes=com.companyGroupId. That way we have best of
two worlds - builds are more defined than with snaphots usage, doesn't require
manual bumping of libraries, but in case when repeated build is neaded one can
easily check the exact used components version.
The main concern raised in the discussion is of course valid, as with artifacts
available in public repositories one cannot be so sure about actors itentions,
as with artifacts used internally and released to internal repositories/nexus
instances. Maybe the solution would be to have some setting at *repository*
entry level whether version ranges are allowed or not (the same like currently
there is a flag whether snapshot / release versions are to be used from given
repository or not). Or to have the resolution strategy at the *repository*
entry level (like prefer lower / prefer higher).
Personally (or rather professionally) I would even seen the extension to the
supported version ranges syntax: MNG-8652 and planned to contribute that change
to have better flexibility when using gradle and maven in different
subcomponents. But as the issue got linked to this one, looks like the
preferred solution would be to get away from maven at all :(.
> 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: Major
> Fix For: 4.x / Backlog
>
>
> 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)
