Adjust the setting's scope to enhance security

[testforstephen]

Signed-off-by: Jinbo Wang [email protected]

The settings that allows you to specify an executable to perform some operation on startup should only be defined in the user settings, and not at workspace scope.

[testforstephen]

Below are the commonly used scope definition:

• application
  Configuration that can be configured only in the user settings.
• machine
  Configuration that can be configured only in the user settings or only in the remote settings.
• machine-overridable
  Machine configuration that can be configured also in workspace or folder settings.
• window
  Configuration that can be configured in the user, remote or workspace settings.
• resource
  Configuration that can be configured in the user, remote, workspace or folder settings.

Sort them by granularity:
application > machine > machine-overridable > window > resource

machine-overridable, window and resource can be configured at workspace scope, should not use it for path settings. The next step is to determine between application and machine.

application VS machine:
application can only be configured in user settings. Local and Remote will share the same one. And remote machine cannot override it.
machine only applies to the machine that configured it. Your local setting won't be shared with remote machine. Need reconfigure it in remote machine.

Regarding the gradle arguments, it could define script path, should be machine specific. So prefer to use machine scope for it.

[testforstephen]

machine VS machine-overridable:
Both are machine specific, your local setting will be ignored by remote machine. But machine-overridable can also be override at workspace/folder settings.

[testforstephen]

// @akaroml @Eskibear @jdneo

[fbricon]

that means all projects will share the same gradle arguments. Seems wrong

[testforstephen]

YES. Regarding security, putting it at workspace scope is vulnerable.

And in Intellij IDEA, this parameter is even not exposed to user. Did you have some specific user scenarios that strongly require it overridable at workspace or project level?

[fbricon]

@snjeza ^^?

[snjeza]

I believe it is a missing feature in Intellij IDEA. Eclipse allows the property to be set at the project level.

[Eskibear]

Cons for each option are listed below in short, we can compare the serverity and tradeoff, and then determine which to use...

• application: blocks remote scenarios, as no way to configure in remote environments like WSL/docker container/etc.
• machine-overridable/window/resource: security issue for anyone who simply clones and opens an opensource repo with malicious settings. (because it's stored in <project_root>/.vscode/settings.json)
• machine: cannot be set per project, have to share one for all projects.

[testforstephen]

Actually most of Gradle command line arguments can be configured by gradle.properties, that can be saved at the project level. This means the user still has alternative to customize the build environment at the project level. The main purpose here is to disable Gradle init script at project level because project scope settings can be saved in git and distribute to others. Both IJ and VS Code are auto import, that will auto load init scripts silently. That's probably the reason why IJ doesn't expose it for import/open.

Eclipse is not auto import, the user need click the wizard step by step to finish the import. It's the user's choice to execute the operation. That's the difference from the security perspective. Also, the import wizard of Eclipse turns off the project's level settings by default, you need manually turn it on.

[fbricon]

merged as 4718da6 (also changes java.import.gradle.jvmArguments scope to machine.