The gradle wrapper validator won't work in the machine without internet access

[testforstephen]

To reproduce it with the latest CI build:

1. Turn off your wifi and keep it without internet access.
2. Clean up ~/tooling/gradle, local gradle user home ~/.gradle, and leave all gradle vscode settings to the default value.
3. Open a sample gradle wrapper project below in VS Code.
   springbootgradledemo.zip
4. You would be prompted about security warning, and click Trust to continue.
5. Even though the LS status is 👍, but actually it fails to import the gradle project. No .classpath is generated. No projects are displayed in the Java Dependency View.

Both GradleProjectImporter and update project configuration failed with exception. See log.txt for more details.

[fbricon]

@testforstephen did you try with "java.import.gradle.offline.enabled": true?

[testforstephen]

YES, enable/disable offline has the same failure.

https://github.com/eclipse/eclipse.jdt.ls/blob/8d33bd04b8ce58fae5fc6dbf69362ea8ed52d9ab/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/managers/GradleProjectImporter.java#L127-L177

When importing project, the wrapper validator will check and send a security warn about suspicious wrapper to client. Meanwhile, the GradleProjectImporter job keeps going and falls back to the default gradle distribution (e.g. 6.3) defined by buildship to import project. It looks like whatever gradle distribution you are using, the tool always needs download the corresponding binary to gradle user home. That's why the first import fails.

When clicking Trust to continue, it will trigger a job to update project configuration. But the update job will call the old GradleBuild to check whether it's root. However, the old GradleBuild will throw the same exception as the first time, that makes update job do nothing.

	@Override
	public void update(IProject project, boolean force, IProgressMonitor monitor) throws CoreException {
		if (!applies(project)) {
			return;
		}
		JavaLanguageServerPlugin.logInfo("Starting Gradle update for " + project.getName());
		Optional<GradleBuild> build = GradleCore.getWorkspace().getBuild(project);
		if (build.isPresent()) {
			GradleBuild gradleBuild = build.get();
			boolean isRoot = isRoot(project, gradleBuild, monitor);
			if (force && isRoot) {
				String projectPath = project.getLocation().toFile().getAbsolutePath();
				BuildConfiguration buildConfiguration = GradleProjectImporter.getBuildConfiguration(Paths.get(projectPath));
				gradleBuild = GradleCore.getWorkspace().createBuild(buildConfiguration);
			}
			if (isRoot) {
				gradleBuild.synchronize(monitor);
			}
		}
	}

[fbricon]

Buildship itself is trying and failing to read the available gradle versions online

[testforstephen]

Buildship itself is trying and failing to read the available gradle versions online

YES, but seems it's not a blocking failure.

[fbricon]

Related: eclipse/buildship#998

[snjeza]

@fbricon @testforstephen See #901 (comment)

[testforstephen]

Here are the download jobs during initializing gradle projects:

• Download PublishedGradleVersions (This is mentioned by Add configuration option to use CACHED_ONLY strategy for downloading published Gradle versions eclipse/buildship#998 and Why it downloads Gradle when I open a single java file #901 (comment))
  Since only GradleProjectImporter is using the result from PublishedGradleVersions, its failure should not affect the importer.

• Download checksums
  I tried to install 0.61.0 (without wrapper validator) and then import a sample gradle wrapper project with gradle-wrapper.jar missing (e.g. delete it on purpose), actually the language server can successfully import it. So looks like buildship won't invoke gradle-wrapper.jar.
  From my understanding, only gradle\wrapper\gradle-wrapper.properties is needed by buildship, and buildship uses the Gradle Tooling API to download the corresponding distribution and get models. Right? // @fbricon @snjeza

• Download Gradle Distribution
  For wrapper, user can specify a local distribution path in the gradle-wrapper.properties to avoid downloading from internet.
  But in current 0.62.0, because the validator failed to detect it's a valid wrapper, it will prompt a notification to client and meanwhile keeping importing workspace with a default distribution 6.3, that will cause a new download request. That's why it failed even though you click "Trust" to continue.

• Download dependencies
  offline mode takes effect for this part, it controls to use the local dependencies instead remote.

[fbricon]

eclipse-jdtls/eclipse.jdt.ls#1486 should help

[DPUkyle]

This is especially problematic as some organizations (like mine) publish a custom, internal-only distribution of Gradle only for use behind their firewall. Buildship and JLS need to be able to support this use-case.

[snjeza]

This is especially problematic as some organizations (like mine) publish a custom, internal-only distribution of Gradle only for use behind their firewall. Buildship and JLS need to be able to support this use-case.

@DPUkyle See https://github.com/redhat-developer/vscode-java/wiki/Gradle-Support#suspicious-gradle-wrapper-detection-

[DPUkyle]

Thank you - very useful!

[fbricon]

@testforstephen with eclipse-jdtls/eclipse.jdt.ls#1486 merged, the gradle validator no longer complains about the malicious wrapper, when offline. Can you check if it's good enough to close this?

[testforstephen]

I see, the offline checksum will mitigate the gradle wrapper validator for bad network scenario. But it doesn't completely solve the offline problem. In fact, gradle wrapper doesn't really work in OFFLINE, because buildship still needs download the gradle distribution specified by the gradle-wrapper.properties from internet. In OFFLINE mode, only the local gradle home java.import.gradle.home works.

One improvement I can think of at the moment is polishing the description about the gradle user setting.

For example, JLS provides three user settings about specifying a gradle distribution, but the description is not intuitive.

• java.import.gradle.wrapper.enabled - Enable/disable Gradle wrapper. Defaults to true.
• java.import.gradle.version - Gradle version, used if the gradle wrapper is missing or disabled.
• java.import.gradle.home - Setting for GRADLE_HOME

If the user specifies the gradle home via java.import.gradle.home, this setting might not take effect. Because JLS will check the wrapper setting first, and use wrapper distribution if your project contains gradlew script. In order to use the local gradle home, you must disable wrapper and the fixed gradle version settings at the same. The current user setting doesn't reflect the implicit relationship of these settings.

Another question is about the gradle security, i got new update and will sync up with you offline.