Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configurable Command Plugin Permissions #1297

Conversation

plemarquand
Copy link
Contributor

Packages can define their own plugins either directly or through their dependencies. These plugins define commands, and the extension exposes a list of these when you use > Swift: Run Command Plugin.

If a command requires special permissions to write to disk or use the network the user is prompted in the integrated terminal to type "yes". This can be bypassed by passing a permission flag to the command such as --allow-writing-to-package-directory. The extension does supply permission flags for a small list of well known package plugins, however if the user creates their own or uses one not on this list they must enter "yes" every time they run the command plugin.

This patch introduces a new setting that can be specified globally or on a per workspace folder basis that allows users to configure which permission flags should be used when running the command.

The setting is defined under swift.pluginPermissions, and is specified as an object in the following form:

{
	"PluginCommandName:intent-name": {
		"allowWritingToPackageDirectory": true,
		"allowWritingToDirectory: "/some/path",
		"allowNetworkConnections: "all",
		"disableSandbox": true,
	}
}

Issue: #1277

Packages can define their own plugins either directly or through their
dependencies. These plugins define commands, and the extension exposes a
list of these when you use `> Swift: Run Command Plugin`.

If a command requires special permissions to write to disk or use the
network the user is prompted in the integrated terminal to type "yes".
This can be bypassed by passing a permission flag to the command such as
`--allow-writing-to-package-directory`. The extension does supply
permission flags for a small list of well known package plugins, however
if the user creates their own or uses one not on this list they must
enter "yes" every time they run the command plugin.

This patch introduces a new setting that can be specified globally or on
a per workspace folder basis that allows users to configure which
permission flags should be used when running the command.

The setting is defined under `swift.pluginPermissions`, and is specified
as an object in the following form:

```json
{
	"PluginName:intent-name": {
		"allowWritingToPackageDirectory": true,
		"allowWritingToDirectory: "/some/path",
		"allowNetworkConnections: "all",
		"disableSandbox": true,
	}
}
```

- The top level string key is the command id in the form
  `command_name:intent_name`. For instance, swift-format's
  format-source-code command would be specified as
  `swift-format:format-source-code`
- Each permission in the permissions lookup is optional.
- `allowWritingToDirectory` can also be specified as an array of paths.
- The valid values for `allowNetworkConnections` can be found here:
  https://github.com/swiftlang/swift-package-manager/blob/0401a2ae55077cfd1f4c0acd43ae0a1a56ab21ef/Sources/Commands/PackageCommands/PluginCommand.swift#L62

Issue: swiftlang#1277
@adam-fowler
Copy link
Contributor

Just to say the way I've got around this so far is click on the cog to create a task in tasks.json and edit the task. I added a field to enable writing to the package directory and a few other options.

This PR is still valid but the solution above should also be advertised as an option as it provides a more fine grained control.

@plemarquand
Copy link
Contributor Author

plemarquand commented Jan 4, 2025

@adam-fowler thanks for the heads up. I've made sure that this patch still works with the tasks.json permission based setup. It also adds support to pass --allow-writing-to-directory and --allow-network-connections by setting allowWritingToDirectory and allowNetworkConnections on the task respectively.

One of the outstanding things left for this PR is to properly document this behaviour both in the package.json settings markdownDescription and in the additional settings documentation.

@plemarquand plemarquand marked this pull request as ready for review January 6, 2025 12:39
@plemarquand
Copy link
Contributor Author

@MahdiBM please take a look and let me know if this addresses all your concerns from #1277

@MahdiBM
Copy link
Contributor

MahdiBM commented Jan 6, 2025

@plemarquand looks great, thank you.

}
]
},
"allowNetworkConnections": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this not be declared as an "enum" with the values SwiftPM accepts?
Even if SwiftPM makes a change, it's trivial for this plugin to update the values and do a release (theoretically at least, not sure what release policies this repo follows).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost, but the local and all cases have associated values. local, local:1234 and local:1234,4321 are all valid values, which complicates a straight mapping here in the settings definition.

@plemarquand plemarquand merged commit 04397b7 into swiftlang:main Jan 7, 2025
15 checks passed
@plemarquand plemarquand deleted the command-plugin-permission-configuration branch January 7, 2025 17:01
@MahdiBM
Copy link
Contributor

MahdiBM commented Jan 7, 2025

@plemarquand What's the release process in this repo, when can I expect this change to be released (or pre-released)? 🙂

@plemarquand
Copy link
Contributor Author

@MahdiBM There is no strict cadence, but it should be available in then next release in the next week or two. If you'd like to try it out beforehand you can follow these instructions to build your own .vsix package from main and install it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants