Fixes :: #1489 :: Add security warnings against version ranges and special version qualifiers #1494
Conversation
…ifiers Signed-off-by: Harsh Mehta <harshmehta010102@gmail.com>
| If you want to use Maven to build untrusted code, it is up to you to | ||
| provide the required isolation. | ||
|
|
||
| ## Security Best Practices |
There was a problem hiding this comment.
I don't see the warning on this page. In my opinion this page is about CVE things.
| Maven picks the highest version of each project that satisfies all the hard requirements of the dependencies on that project. | ||
| If no version satisfies all the hard requirements, the build fails. | ||
|
|
||
| **Security Warning**: The use of version ranges (hard requirements with brackets and parentheses) is **strongly discouraged** due to security concerns. Version ranges introduce unpredictability in builds, can lead to non-reproducible builds, and may unexpectedly pull in vulnerable versions of dependencies. Always prefer using explicit, fixed version numbers for dependencies to ensure build reproducibility and security. For similar reasons, the use of `min` and `max` suffixes in version strings should also be avoided (see [Version Order Specification](#version-order-specification) below). |
There was a problem hiding this comment.
I would like to only have warning a warning on this page that using those (as well as min/max, latest etc) are not recommended as they can lead to undesired behavior and pulled in artifacts and that we recommend using the enforcer-rule to enforce it. And then link to the page where version ranges are described, which is https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html and which also needs a warning with a more detailed explanation and examples and a link to the rule.
(at @elharo For me it's very similar to the system dependency: Maven support it and there are reasons to use it. Are those special and situations are rare? Yes, but they are there. So Maven should not warn about itself having a security problem, but explain it as best practice to avoid this pitfall. It's not a security problem of Maven, but of every automatic dependency mechanism.
There was a problem hiding this comment.
No,, this is much worse than system dependencies. It should never have been added and should never be used..
There was a problem hiding this comment.
also, not all uses of brackets and parentheses introduce version ranges. They can also be used to pin a specific version during transitive dependency resolution
| Maven picks the highest version of each project that satisfies all the hard requirements of the dependencies on that project. | ||
| If no version satisfies all the hard requirements, the build fails. | ||
|
|
||
| **Security Warning**: The use of version ranges (hard requirements with brackets and parentheses) is **strongly discouraged** due to security concerns. Version ranges introduce unpredictability in builds, can lead to non-reproducible builds, and may unexpectedly pull in vulnerable versions of dependencies. Always prefer using explicit, fixed version numbers for dependencies to ensure build reproducibility and security. For similar reasons, the use of `min` and `max` suffixes in version strings should also be avoided (see [Version Order Specification](#version-order-specification) below). |
There was a problem hiding this comment.
also, not all uses of brackets and parentheses introduce version ranges. They can also be used to pin a specific version during transitive dependency resolution
3 participants
Fixes : #1489
Following this checklist to help us incorporate your
contribution quickly and easily:
Note that commits might be squashed by a maintainer on merge.
mvn siteand examine output intarget/sitedirectory.Site will also be built on your pull request automatically and attached to GitHub Action result.
If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.