-
-
Notifications
You must be signed in to change notification settings - Fork 271
Description
As discussed in #1710, it's a major security issue that simply opening a file enables running of arbitrary executable code in the file's directory, making it inherently unsafe to even simply view a file from an untrusted source in Sublime Text if you have SublimeLinter and any relevant linter installed. As an example, if you clone this repo or open this .zip file, and open the .js file in SublimeText with SublimeLinter-eslint installed, and it will run the arbitrary code (dropping a file in your home dir / on your desktop).
To be safe, by default, SublimeLinter should only run executables installed by the user (or provided by SublimeLinter- packages if that's done), not file-relative executables. The existing behavior of searching relative to the linted file should still be enableable at the user level. Arguably not per-project, otherwise, obviously, a malicious project would just change the option in a project file, but opening a .sublime-project file from an untrusted source is already a bit sketchy, so that might be reasonable to allow, and would satisfy most common use scenarios.
I'd also argue this is a usability issue, as more than once I've been bitten by SublimeLinter stopping working in some folders, for, at the time, unknown reasons, but probably due to issues like #1710, but probably also when opening freshly cloned repos that I wouldn't trust enough to run npm install in, or often when traveling, didn't have the bandwidth to run npm install in.
I realize that any packages delivered through Package Control or NPM are significant security risks, as the authors can generally all execute arbitrary code at install- and run-time, however that has a layer of trust and accountability that doesn't exist when you just want to look at the source code for a cool thing someone just posted to Reddit ^_^.