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

Look into user-friendlier ways to allow users to opt into using phan for trusted folders #95

Open
TysonAndre opened this issue Apr 17, 2021 · 0 comments

Comments

@TysonAndre
Copy link
Owner

(and by default, only start language servers corresponding to files/folders that are open)

I'd been discussing how this could be done in a user-friendly and safe way with the reporter of CVE-2021-31416

For current vscode versions:

I looked into how https://github.com/microsoft/vscode-maven/pull/526/files handled it since the Memento API is backed by a sqlite database in a global configuration database (in a user's home directory?), which is reasonable.

  • The first time phan opens a folder and finds a .phan/config.php, prompt the user if they want to trust the extension before executing anything (e.g. checking the php version, etc)

For future vscode versions

There's a feature being previewed right now.

microsoft/vscode#106488 is something along the lines of what I wanted to use for Phan, but it wasn't available when I first published this extension (with respect to phan configs and phan plugins being/invoking executable code by design, etc)

The trusted workspaces concept is intended to centralize and unify a security conscious decision required by a variety of VS Code features. The easiest existing example to understand of this decision is with the ESLint extension. The ESLint extension will try to use the eslint module in the current folder that is opened in VS Code and execute code from it. Since you may have checked out a random repository from the web, this could be dangerous if the repository contains a corrupt eslint module. Notice that ESLint is not trying to be malicious, but rather, the repository/corrupt module is taking advantage of this automatic code execution.

Related to #83

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

No branches or pull requests

1 participant