[MNG-8569] Deprecate and remove version ranges

[jira-importer]

Elliotte Rusty Harold opened MNG-8569 and commented

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:

1. Discourage this in the docs for version ranges, especially the POM reference.
2. Warn about this in the build when version ranges are encountered.
3. Formally deprecate the relevant code in the repo. (Might not be necessary.)
4. Add a switch (system property) to disable version ranges. Switch is off by default.
5. Turn the switch on by default. 
6. 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.

 

 

---

Issue Links:

• MNG-8652 Support prefix version ranges for better interoperatibility

• MNG-6049 Add behavior to filter resolved version ranges of an artifact

[jira-importer]

Guillaume Nodet commented

What about targeting model 4.1.0 ?

[jira-importer]

Guillaume Nodet commented

Would it be better to change how version ranges are handled ?

If the problem is that Maven will automatically select the highest version, should we rather change the behavior to select the lowest version ? That would be more in line with the non range behavior, where <version>[2.1,)</version> would actually behave like <version>2.1</version>

This would allow to keep the feature of closed ranges, where you know that you're only compatible with a limited range: <version>[2.1,3)</version>.

[jira-importer]

Tamas Cservenak commented

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"

[jira-importer]

Tamas Cservenak commented

gnodet Maven4 already have that:

maven/api/maven-api-core/src/main/java/org/apache/maven/api/Constants.java

Lines 298 to 317 in f3000ee

	/**
	* User property for version filter expression used in session, applied to resolving ranges: a semicolon separated
	* list of filters to apply. By default, no version filter is applied (like in Maven 3).
	* <br/>
	* Supported filters:
	* <ul>
	* <li>"h" or "h(num)" - highest version or top list of highest ones filter</li>
	* <li>"l" or "l(num)" - lowest version or bottom list of lowest ones filter</li>
	* <li>"s" - contextual snapshot filter</li>
	* <li>"e(G:A:V)" - predicate filter (leaves out G:A:V from range, if hit, V can be range)</li>
	* </ul>
	* Example filter expression: <code>"h(5);s;e(org.foo:bar:1)</code> will cause: ranges are filtered for "top 5" (instead
	* full range), snapshots are banned if root project is not a snapshot, and if range for <code>org.foo:bar</code> is
	* being processed, version 1 is omitted. Value in this property builds
	* <code>org.eclipse.aether.collection.VersionFilter</code> instance.
	*
	* @since 4.0.0
	*/
	@Config
	public static final String MAVEN_VERSION_FILTER = "maven.session.versionFilter";

[jira-importer]

Elliotte Rusty Harold commented

This is a long-term goal. I think model version 4.1 or later would be required before we remove it completely. We can warn against it more strenuously in earlier versions.

[jira-importer]

Guillaume Nodet commented

I see two things that could be done:

• have a way to configure which version is selected in a given range: Maven currently selects the highest, but we could make it configurable so that the lowest would be selected by default (this is different than the MAVEN_VERSION_FILTER property which actually changes the output of the range resolution
• change the consumer POM to not use range, but rather use the resolved version

I think ranges can be useful to express which versions of a given dependency are supported, but I'm not really sure why this would imply to always select the highest one.

Or maybe extend the syntax to support specifying the default version: <version>2.1[2,3)</version> which would mean select version 2.1 by default, the range being 2,3). (or any other syntax).
We could then warn if no default version is specified.

[jira-importer]

Elliotte Rusty Harold commented

If you're selecting the lowest or a default version, would this be just the same as specifying that version explicitly?

Also, the reason developers use ranges is generally to automatically pick up the latest release, possibly within a major version, without having to notice it's been released and change their code, so I'm not sure anyone will really want the lowest version.

The problem with offering a version range is not that the developer's goal is bad. It's that it's insecure due to bad actors.

[jira-importer]

Guillaume Nodet commented

If you're selecting the lowest or a default version, would this be just the same as specifying that version explicitly?

Yes if you're using an open range. No if the range is closed such as {}[2.1,3]{}.

Also, the reason developers use ranges is generally to automatically pick up the latest release, possibly within a major version, without having to notice it's been released and change their code, so I'm not sure anyone will really want the lowest version.

Yes, I'm mostly focusing on restricting the range to a list of compatible versions. I think that's a valid use case.

[jira-importer]

Elliotte Rusty Harold commented

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?

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.

[jira-importer]

Guillaume Nodet commented

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?

If another dependency depends on the same artifact with a 2.2 version, the conflict resolution will select 2.2 for the whole tree.

 

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

[jira-importer]

Elliotte Rusty Harold commented

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.

[jira-importer]

Guillaume Nodet commented

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.

[jira-importer]

Elliotte Rusty Harold commented

This is about what's directly declared, not what's transitive. As long as transitive dependencies specify specific versions it's all safe. The problem is not getting a higher version than what the pom declares. The problem is you might end up with a version that has not been released yet, and might have deliberately introduced backdoors.

If a particular project wants to avoid transitive dependencies upgrading a another dependency they can user a single version hard dependency such as [2.1].

[jira-importer]

Guillaume Nodet commented

 The problem is not getting a higher version than what the pom declares. The problem is you might end up with a version that has not been released yet.

Right, so the problem is automatically getting the highest version.  Which is what I'm proposing to change by always selecting the lowest version of the range (or extending the syntax).

[jira-importer]

Elliotte Rusty Harold commented

Maybe I'm not understanding you. Are you suggesting that we change the current behavior so that [2.1,3) is the same as [2.1]? or that

<version>[2.1,3)</version>

is the same as

<version>2.1</version>

Or is there some way it would differ that I'm not seeing?