Popups with every folder I open

[kasvtv]

With every project folder that I open in VScode (File > Open folder...) I get the following popup:

"The eslint extension will use the eslint library node_modules/eslint installed locally to the workspace folder 'reponame' for validation. Do you allow this?"

This is really annoying and when the popup window is just closed without giving permission, ESlint will not load at all. This is a huge problem, because it was already hard enough to have teammates respect a linter, let alone when an annoying unexpected popup occurs that one is likely to dismiss, which will not make it load at all.

Is there anything regarding project configuration that will prevent this popup from occurring and just make ESlint work by default like it always did?

[spersico]

I'm seeing this too since yesterday, and I didn't change anything, though yesterday VSCode updated itself so it could be a VSCode problem. I'm using WSL2 Ubuntu 20.04.

[TurboLion]

I saw this popup after VS Code updated to version 1.47.1 and I clicked on "Allow"; after that I had a couple weird bugs with auto-import not working in a React project, not sure if this is related to the popup or not.

[Lightfire228]

Probably related to the security patch 1.47.1 for vscode

The MS CVE says

An elevation of privilege vulnerability exists in Visual Studio and Visual Studio Code when they load software dependencies. ...

So I'd imagine that popup is related to the change in how external dependencies are loaded

[chrisdias]

@Lightfire228 that is correct, both VS Code and the ESLint extensions were updated yesterday.

Suggestion: Improve the message to make it more clear, such as:

The ESLint extension found the eslint executable in node_modules/eslint. If you trust this version of eslint, press OK. For more information, please see [link to a doc].

With the following options:

[Ok] [Cancel] [Don't Show Again]

//cc @kieferrm @misolori

[eamodio]

Alternate suggestion:

The ESLint extension will use the node_modules/eslint version of ESLint for validation, which installed locally to the workspace folder folder-name. If you trust this version of ESLint, press Allow. Otherwise, press Disallow, to disable ESLint for the workspace folder folder-name, or Cancel, to disable ESLint just for this session.

[Allow] [Disallow] [Cancel]

[spersico]

The most important thing to me, is to have a flag that always allows eslint to be run for the entire workspace, or globaly. Because, for some reason, VSC showed me this message inside of the same workspace like a hundred times today 😞

[chrisdias]

are you pressing Cancel each time, or Yes or No?

[spersico]

The first time, I pressed yes, and it kept opening when I changed files. Then, after a few restarts of VSC, I pressed no, and still, it kept opening, same behaviour. With cancel, same behaviour. At some point, I pressed Yes, and the error went away, and it started working properly.

On Jul 15 2020, at 7:22 pm, Chris Dias notifications@github.com wrote:

are you pressing Cancel each time, or Yes or No? — You are receiving this because you commented. Reply to this email directly, view it on GitHub (https://link.getmailspring.com/link/FC270590-AB5B-4573-A2EC-DF708ECB2DAF@getmailspring.com/0?redirect=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fvscode-eslint%2Fissues%2F1012%23issuecomment-659045027&recipient=cmVwbHkrQUNRRURUUDI1NDNKV0IzWEdWSFNaRDU1RE5SSkRFVkJOSEhDT0xXS1Y0QHJlcGx5LmdpdGh1Yi5jb20%3D), or unsubscribe (https://link.getmailspring.com/link/FC270590-AB5B-4573-A2EC-DF708ECB2DAF@getmailspring.com/1?redirect=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACQEDTLBVYH6FLS7FNZWF73R3YTZDANCNFSM4O2SIYMQ&recipient=cmVwbHkrQUNRRURUUDI1NDNKV0IzWEdWSFNaRDU1RE5SSkRFVkJOSEhDT0xXS1Y0QHJlcGx5LmdpdGh1Yi5jb20%3D).

[kieferrm]

Changed the buttons to 'Allow' and 'Do Not Allow' and the message to

The ESLint extension will use '${relativePath}' for validation, which is installed locally in '${folder.name}'. If you trust this version of ESLint, press 'Allow', otherwise press 'Do Not Allow'. Press 'Cancel' to disable ESLint for this session.

There was also a bug that caused the confirmation dialog to pop up for all open editors when the user did not trust the local version and answered with 'No' (now 'Do Not Allow'). I suspect that this is what @spersico has experienced.

[kieferrm]

@kasvtv we can't introduce a project setting here. The scenario the change is addressing is 1) You clone a repo, for example from GH, that has node_modules/eslint checked in, and then you open a file that eslint checks in VS Code 2) You download a zip of a repo, for example from GH, that contains node_modules/eslint inside, you unzip, and then you open a file that eslint checks in VS Code

[sarahsga]

I chose "Allow" every time this popup appeared, and now my auto-format on save has stopped working!

[s-h-a-d-o-w]

I think there should be a global setting to completely disable this behavior. It should be possible for a user to choose comfort over security, since there are probably many who don't use random eslint installations but always get them from npmjs.

[rjgotten]

@kieferrm we can't introduce a project setting here. The scenario the change is addressing is (...)

Be that as it may, the entire thing is still a major annoyance and there are better solutions possible that choose a mid-road between (overly) stringent security and comfort.

A very simple one is to put the user in control and allow them to opt-out of this behavior by turning it off. A more involved one would reduce the amount of times the prompt appears by comparing the installed eslint module against a set of known integrity hashes, instead of making it an explicit per-folder choice.

[coreyward]

@kieferrm I do not have node_modules under SCM and the dependencies were installed via yarn (not an unzipped project repo), but this still shows for me in every relevant project. I suspect something is wrong with the source tracking.

[tgreen7]

How about an "Always Allow" option? Or at least a setting that we can configure to disable this popup?

[andygock]

Having a config setting to "always use local install ESLint for validation when available" would be a good option. Having a interactive popup interrupting the user for every single project that is opened isn't great.

[dbaeumer]

Regarding some of the suggestions:

• always using a global installed ESLint version is not possible of all the version differences that exists. On top older ESLint version are very sensitive to loading plugins depending on whether ESLint is loaded globally or locally.
• detecting how the local ESLint version came on disk is very hard and might lead to problems as well. Simply the fact that it was not under Git doesn't mean it came via npm install.
• using hash codes to trust certain versions can easily fail with .eslintrc.js files and plugins.

[rjgotten]

using hash codes to trust certain versions can easily fail with .eslintrc.js files and plugins.

And this is in truth no different when looking at the scenario where a prompt explicitly asks you to trust a version of ESLint installed in a particular folder. Trusting that installation of ESLint does not and should not make a plugin referenced via an .eslintrc.js file implicitly trust-worthy either.

Even if you'd use a global installed ESLint, an ESLint plugin loaded via an .eslintrc.js config file can still come from any number of untrusted locations - including a folder within a repository downloaded as source code. In fact, you don't even have to look at plugins, as the .eslintrc.js is a JavaScript file and can require and run whatever the hell it wants.

In conclusion, the premise that adding this popup dialog offers any kind of additional security is flawed to begin with. And thus only the UX downside of having to click "Allow" each time remains.

[dbaeumer]

I will update the message to make this more clear.

[jsejcksn]

@dbaeumer When we select "Allow" or "Deny" in this dialog for each workspace: Where are our preferences being stored?

[dbaeumer]

@jsejcksn in a scoped store that the VS Code API provides to me.

[rjgotten]

I will update the message to make this more clear.

Just to get this straight: you're going to point out in the popup-message that you're pestering the user for a net zero gain in actual security, unless they vet the whole folder / workspace?

Over just axing the feature because it's effectively useless to prevent what you set out to prevent with it, because it's a UX nightmare and everyone will end up just clicking on "Agree" / "Allow" ? Or atleast offering an option to turn it off?

Ok then...

[dbaeumer]

IMO the right solution is to have something like a trusted workspace in VS Code itself which would make the whole concept more first class and will for example allow to trust certain GitHub URLs as well (e.g. trust every repository under https://github.com/myOrg like VS Code does for browser URLs). I have cycled that back to the corresponding devs in the VS Code team.

[rjgotten]

I was just going to point out as well that having either a workspace-level sandbox or a concept of 'scoped trust' / trusted scope' would be the way to truly solve this. Hope to see the VS Code team respond to that.

[jsejcksn]

@dbaeumer I understand that there might be some discussion involved to make a decision about how to address this. Perhaps right now, you can switch from a blocking modal dialog to something like vscode.window.showInformationMessage or vscode.window.showWarningMessage with selectable options in the notification. This would be more in line with the expected behavior of other extensions and wouldn't force the user to select an option to be able to use the workspace.

[rjgotten]

@jsejcksn Perhaps right now, you can switch from a blocking modal dialog

Using non-blocking notifications presents a different problem though: too easy for developers to forget to allow the linter to run and they'll work without feedback, only to be confronted with a pile-on of linting violations when e.g. a commit hook enforces linting conformation.

[jsejcksn]

@rjgotten A developer's ignoring notifications is a kind of personal issue, not one specific to this or any other extension.

No modal should ever disrupt interactions which are not directly related to the purpose of the modal.

This is a case where a modal dialog is inappropriate.

[spersico]

These are, IMO the best approachs:

• a global setting so that VSCode doesn't show me any message related to plugins running from any local project.
• a per-workspace setting, so that VSCode doesn't show me any message related to plugins running from this local project.
• Clear up the wording in the modal dialog, it's not clear what's happening, nor what's the result of pressing each button.
• I assume that what happened with my VSC was a bug (asking again and a again abut eslint, no matter what choice I selected), it no longer happens. I assume that when I rebooted my PC it magically fixed itself. But it shouldn't have happened, I'm not sure how you could be able to replicate the issue though.

[jjensen-ebsco]

How do we unset or change whatever setting the popup sets? I'm now getting errors for every single carriage return in my code.

[andygock]

@jjensen-ebsco As a workaround, until this gets resolved, you can right click on the extension and select "Install Another Version...", version 2.1.6 seems to not have this focus stealing popup issue. Reload/restart required.

[dbaeumer]

@jjensen-ebsco this is very likely unrelated to the dialog since it doesn't change any of the ESLint rules.

To manage the saved premissions run the following command ESLint: Reset Library Decisions

[chenchenwuai]

With every project folder that I open in VScode (File > Open folder...) I get the following popup:

"The eslint extension will use the eslint library node_modules/eslint installed locally to the workspace folder 'reponame' for validation. Do you allow this?"

This is really annoying and when the popup window is just closed without giving permission, ESlint will not load at all. This is a huge problem, because it was already hard enough to have teammates respect a linter, let alone when an annoying unexpected popup occurs that one is likely to dismiss, which will not make it load at all.

Is there anything regarding project configuration that will prevent this popup from occurring and just make ESlint work by default like it always did?

Downgrade eslint to version 2.1.4

[chenbingchang]

每次出现此弹出窗口时，我都选择“允许”，现在保存时我的自动格式已停止工作！

I choose "not allowed". Now my auto format has stopped working when saving!

[dbaeumer]

@chenbingchang this is expected. If you don't allow the extension to load the ESLint library auto format will not work either.

[OriAmir]

How could I change my decision ? in mistake I clicked "now allowed" and then it's stop to show me eslint errors on the editor. I have to downgrade a version of the extension to make it work, the question if we could change the popup decision?

[ghost]

How does one make an educated decision on whether to trust one projects node_modules/eslint over another?

Otherwise - I'm pretty much always going to trust eslint unless I read some news about a security breach in the published package.

[dbaeumer]

@OriAmir To manage the saved permissions run the following command ESLint: Reset Library Decisions

[rjgotten]

How does one make an educated decision on whether to trust one projects node_modules/eslint over another?

One typically doesn't. It's not just eslint which needs to be trustworthy. It's also all its dependencies ; any plugins loaded via an .eslintrc.js file; and their dependencies. The average ESLint user is not going to vet their entire package tree. They're just going to do what you're planning to do:

Otherwise - I'm pretty much always going to trust eslint unless I read some news about a security breach in the published package.

And that's why the existence of this dialog is bad. It trains users to just hit "Allow" and go on with their work.

[amirhoseinsalehi]

How could I change my decision ? in mistake I clicked "now allowed" and then it's stop to show me eslint errors on the editor. I have to downgrade a version of the extension to make it work, the question if we could change the popup decision?

click on 'ESLint' on downside of vscode and next a popup shows to you and you can reset all eslint settings. :)

[MagicHacker]

so, what's the best solution?

[ryanblock]

@dbaeumer sorry if I missed it, but I've been following this thread and I'm still unclear: will the maintainers of this project be handling this issue? If so, specifically how?

[dbaeumer]

I had longer discussion with the VS Code team about this and there will soon be work happening for a a trusted workspace concept in VS Code itself which the ESLint extension will then adapt to. If a workspace is trusted there will be no need for ESLint to confirm execution.

[ryanblock]

@dbaeumer that's dope! In the mean time will y'all consider rolling this back until this trusted workspace feature ships?

[dbaeumer]

Just to ensure there is not another bug with the dialog. You should only see the dialog once per workspace folder / global install unless you close the dialog with Cancel or Escape.

[jsejcksn]

@dbaeumer If the workspace is not trusted, a blocking modal dialog is still a problem. Did you see my previous suggestion? https://github.com/microsoft/vscode-eslint/issues/1012#issuecomment-660949644

[samselikoff]

This dialog is very costly, as most users who encounter a blocking dialog not triggered by an action they took will take the default action to dismiss it. A blocking dialog is absolutely inappropriate here and I really wish it could get rolled back before the larger "trusted workspace" feature lands!

Also

you should only see the dialog once per workspace folder

is not relevant for those of us who work with many different projects (often OSS) throughout the week.

The dialog is really obnoxious and based on the actual way devs are using it, the benefits don't justify it at all!

At the least, please give us an option to globally approve the ESLint extension to use whatever binary it finds in any project.

[dbaeumer]

@jsejcksn the problem here is that VS Code doesn't offer any API to make the notification sticky meaning that the dialog will go away after n seconds making it easy to miss it. That would mean that ESLint will stay disabled with all the problems that will lead to.

[ryanblock]

As I asked before: in the mean time will y'all consider rolling this back until the trusted workspace feature ships?

[jsejcksn]

@dbaeumer

the dialog will go away after n seconds making it easy to miss it

VS Code provides a persistent symbol for unread notifications:

Unread notifications:

No notifications:

That would mean that ESLint will stay disabled with all the problems that will lead to.

Isn't that the entire purpose of this behavior change: not enabling ESLint without explicit user approval?

I'll quote myself from earlier in this discussion:

A developer's ignoring notifications is a kind of personal issue, not one specific to this or any other extension.

No modal should ever disrupt interactions which are not directly related to the purpose of the modal.

This is a case where a modal dialog is inappropriate.

The current behavior is hostile to users.

[dbaeumer]

Isn't that the entire purpose of this behavior change: not enabling ESLint without explicit user approval?

Yes, but if it is easy to be overlooked I think it is not good either. It will result in lots of user having ESLint being disabled without knowing it. The good thing about having a trusted workspace concept in VS Code itself will make it a lot easier to come up with a good UI since the solution will not be bound to VS Code API capabilities.