[ 
https://issues.apache.org/jira/browse/MNG-8569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925941#comment-17925941
 ] 

Tamas Cservenak commented on MNG-8569:
--------------------------------------

BIG -1
We should not remove this, but better educate, in fact, we do good job in it, 
as Maven users usually do not use ranges, but ranges do have their merit, as 
Chef would say "There's time and place for everything"

> 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)

Reply via email to