Our great sponsors
-
ua-parser-js
UAParser.js - Free & open-source JavaScript library to detect user's Browser, Engine, OS, CPU, and Device type/model. Runs either in browser (client-side) or node.js (server-side).
-
packer.nvim
A use-package inspired plugin manager for Neovim. Uses native packages, supports Luarocks dependencies, written in Lua, allows for expressive config
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Since Neovim 0.5 release (which has full Lua support) I see more and more amazing Lua plugins being developed, and I think this trend will likely to continue. But I recently got more concerned about security risks associated with the way Neovim plugins being installed and used (especially after seeing recent compromises like ua-parser-js or coa). Installing typical Neovim plugin is basically downloading and executing random code from the internet on your machine with your user privileges, so hijacked or deliberately malicious plugin could potentially do a lot of damage (like stealing keys/passwords, installing keylogger or just rm -rf / for fun).
One advantage of this approach is that it doesn't need any changes in Neovim, and could be built separately, completely in Lua. But this is easier said than done: some Neovim API functions (like vim.api.nvim_exec) can do lots of different things based on parameters, so banning them completely won't be practical, but allowing them may not be safe. For such functions, likely a more advanced technique will be required. Maybe using wrapper functions that would perform some parameter analysis and decide whether particular call is allowed or not. One big red flag for me is that if this was easy, Packer probably would've done it.
I think this is essential. Maybe plugin managers could add sandboxes. For example, this lua library is a proof of concept: https://github.com/APItools/sandbox.lua. "Packer" could add a method to load plugins with a sandbox, where you allow/disallow certain resources, something like
You've just pointed out a security hole in my password workflow. I store passwords using pass and occasionally open a password file for editing from the command line, which opens in Neovim. At all other times the passwords are encrypted, but in that window a malicious plugin could look straight in, and would have access to site, username and password.
WASM is not related to JavaScript in any way, it's just a formal definition (see the spec) for a bytecode and a VM that executes it. One of the problems that WASM tries to solve for web development is to get away from JS because it's such a mess. It's unfortunate that WASM has "Web" in its name, as it's rally not just for Web: there are many embedded runtimes, for example, popular proxy server Envoy supports WASM for writing filters (aka extensions) and there's even WASM runtime for the Linux kernel.
This is already possible with firejail, but does not play nice with the shell (I tried playing around with it). Bubblewrap is plain annoying to setup for this due to the huge number of rules necessary (and user modifiavle exceptions etc). Check the firejail profile for vim.
