3 ms·

I love Helix as a vim user for decades. It brings fresh wind in a pretty entrenched world for people that think neovim is not neo enough. That being said, I'm

I love Helix as a vim user for decades. It brings fresh wind in a pretty entrenched world for people that think neovim is not neo enough. That being said, I'm pretty disappointed by the decision for an obscure plugin language. Moreover, I'm disappointed even more, that the necessity of a strong and tried and proven sandbox is not given enough attention. The recent xz disaster just proves once more that we cannot go on like this. An editor that requires tens of plugins from tens of different parties just to be usable will not have a future if it has no answer to the supply chain question. This is really not just vim and neovim, Visual Code Studio is equally bad and most full IDEs are only marginally better. In my opinion zellij is on the right track here and I had wished Helix had adopted a similar solution.

__float 3y ago
I didn't think Helix supported plugins, and I don't see any mention of it in the documentation. What language does it use? (Edit: I see a bit of Scheme in the GitHub repo, but to call them "plugins" are a bit of a stretch; it seems limited to mostly-declarative syntax highlighting stuff.)
- davidkunz 3y ago
  It doesn't yet have a plugin system but they're thinking of adding one for the Steel programming language (a lisp). https://github.com/mattwparas/steel https://github.com/mattwparas/steel
  - weinzierl 3y ago
    Yes, and from what I understand there was plenty of discussion and they carefully analyzed different options. The discussion seems to be is closed now. I respect that, you cannot ponder these things forever and sometimes any decision is better than none. It's just that, unfortunately, my priorities are different from those of the Helix devs in that respect.
multiplied 3y ago
A code editor that doesn't support plugins is destined to die.
boomskats 3y ago
Are you referring to Scheme or to wasm/wasi? The sandboxing would be one of the the biggest benefits with a wasm-based plugin system, but they were waiting for the component model spec to be finalised last time I had a look. edit: looks like the plugin work is being done here https://github.com/helix-editor/helix/pull/8675 https://github.com/helix-editor/helix/pull/8675
djaouen 3y ago
If this is true, it’s a sad day for software. Not sure why some actors are intent on ruining it for the rest of us.
bobbyskelton41 3y ago
I think the xz disaster would be a reason why Wasm-based plugins would be bad. People would be forced to use plugins written in a language they may not know and would not be able to audit for themselves.
- yunohn 3y ago
  A WASM setup should completely sandbox the plugin so even with malicious code, it would not have access to anything sensitive.
  - habitue 3y ago
    Depends. if the editor is given permission to edit files, like say, many people do `sudo helix` when they want to edit some system config file, you could imagine a rogue wasm plugin doing a lot of harm. Sandboxing isn't magic, if you need the permissions to do something, then the things in the sandbox get access to them.
    - yunohn 3y ago
      That’s not how the WASM sandbox usually works - it has a very limited API surface and can only take specified inputs. https://docs.wasmtime.dev/security.html https://docs.wasmtime.dev/security.html
      - habitue 3y ago
        Right, but it can control the editor indirectly through that API surface, and the editor can write to the filesystem. It's definitely more secure than running a non-sandboxed executable, but the entire point of a plugin is to have an effect on the editing process, and the entire point of the editor is to modify files on the filesystem. As long as that's true there's a casual mechanism for an untrusted plugin to do damage.
clot27 3y ago
There was a long discussion regarding this in the community, I am sure they came up with the best idea
- weinzierl 3y ago
  Good discussion with good reasons, very much like the other design decisions that they made so far. I just believe that when it comes to the plug-in idea that their priorities are not the ones that will be important in the long run and that they vastly underestimate the importance as well as the effort of a practical and useable sandbox implementation.

__float 3y ago

I didn't think Helix supported plugins, and I don't see any mention of it in the documentation. What language does it use? (Edit: I see a bit of Scheme in the GitHub repo, but to call them "plugins" are a bit of a stretch; it seems limited to mostly-declarative syntax highlighting stuff.)

davidkunz 3y ago
It doesn't yet have a plugin system but they're thinking of adding one for the Steel programming language (a lisp). https://github.com/mattwparas/steel https://github.com/mattwparas/steel
- weinzierl 3y ago
  Yes, and from what I understand there was plenty of discussion and they carefully analyzed different options. The discussion seems to be is closed now. I respect that, you cannot ponder these things forever and sometimes any decision is better than none. It's just that, unfortunately, my priorities are different from those of the Helix devs in that respect.

multiplied 3y ago

A code editor that doesn't support plugins is destined to die.

boomskats 3y ago

Are you referring to Scheme or to wasm/wasi? The sandboxing would be one of the the biggest benefits with a wasm-based plugin system, but they were waiting for the component model spec to be finalised last time I had a look. edit: looks like the plugin work is being done here https://github.com/helix-editor/helix/pull/8675 https://github.com/helix-editor/helix/pull/8675

djaouen 3y ago

If this is true, it’s a sad day for software. Not sure why some actors are intent on ruining it for the rest of us.

bobbyskelton41 3y ago

I think the xz disaster would be a reason why Wasm-based plugins would be bad. People would be forced to use plugins written in a language they may not know and would not be able to audit for themselves.

yunohn 3y ago
A WASM setup should completely sandbox the plugin so even with malicious code, it would not have access to anything sensitive.
- habitue 3y ago
  Depends. if the editor is given permission to edit files, like say, many people do `sudo helix` when they want to edit some system config file, you could imagine a rogue wasm plugin doing a lot of harm. Sandboxing isn't magic, if you need the permissions to do something, then the things in the sandbox get access to them.
  - yunohn 3y ago
    That’s not how the WASM sandbox usually works - it has a very limited API surface and can only take specified inputs. https://docs.wasmtime.dev/security.html https://docs.wasmtime.dev/security.html
    - habitue 3y ago
      Right, but it can control the editor indirectly through that API surface, and the editor can write to the filesystem. It's definitely more secure than running a non-sandboxed executable, but the entire point of a plugin is to have an effect on the editing process, and the entire point of the editor is to modify files on the filesystem. As long as that's true there's a casual mechanism for an untrusted plugin to do damage.

clot27 3y ago

There was a long discussion regarding this in the community, I am sure they came up with the best idea

weinzierl 3y ago
Good discussion with good reasons, very much like the other design decisions that they made so far. I just believe that when it comes to the plug-in idea that their priorities are not the ones that will be important in the long run and that they vastly underestimate the importance as well as the effort of a practical and useable sandbox implementation.