6 ms·

Giving the maintainers the benefit of the doubt, I think the optimal solution solution would require a lot of thought and work. While I have no doubt that Elisp

by uludag 2y ago

Giving the maintainers the benefit of the doubt, I think the optimal solution solution would require a lot of thought and work. While I have no doubt that Elisp is an environment especially ripe for these kinds of exploits, it's by no means unique to Emacs. Just look at VSCode's solution to this problem: https://code.visualstudio.com/docs/editor/workspace-trust https://code.visualstudio.com/docs/editor/workspace-trust .

hollerith 2y ago
I strongly prefer vscode's solution to the current state of affairs in Emacs.
- uludag 2y ago
  I have no doubt that VSCode has a much less risk of executing code by opening something. Ironically however, it seems that VSCode's extension is the most effective channel to distribute malware in the history of code editors. [1] [2] Not that MELPA couldn't be used to distribute malware either, I just think, as another poster mentioned, these problems are almost more social than technical. [1] https://www.bleepingcomputer.com/news/security/malicious-vscode-extensions-with-millions-of-installs-discovered/ https://www.bleepingcomputer.com/news/security/malicious-vsc... [2] https://arxiv.org/html/2411.07479v1 https://arxiv.org/html/2411.07479v1
  - alwayslikethis 2y ago
    If anything, Emacs users are probably much more likely to inspect the code of whatever extension they are using, since with every help page there is a link to the source code. It helps that it's much less popular and so not as big of a target.
    - deleted 2y ago
      [deleted]
- dietr1ch 2y ago
  Emacs is just too old to be architected with security in mind. It's a great editor, but has baggage that IMHO can't be addressed on the spot. Working on a codebase where you can't (heavily?) break things between any commit imposes such a slow pace that it's not completely unreasonable to start from the ground up and just study what made Emacs great and what didn't work too well. It's surprising how long Emacs has been around and how good of an editor it is. It really makes rewrite attempts such a long stretch that it exhausts the motivation and time out of spirited folks that give it a go, but I think that given how complexity is being modularised and moved out (LSP, DAP, grammars) and newer languages make packaging easier that Emacs will eventually be replaced, definitely without covering everything it can do, but being strong at the average editing session.
  - nextos 2y ago
    That's my opinion as well. I run Emacs 24/7 but I do so inside Firejail, with no network access. It's not architected with security in mind and exploits are too easy. The same can be said about the Linux userland. The Unix model of giving plenty of access to resources and any user file to user processes is outdated. I find it frustrating something like Firejail or bwrap is not standard. I don't want a compromised program to have easy access to e.g. my SSH keys.
    - hollerith 2y ago
      >I run Emacs 24/7 but I do so inside Firejail Can you share your Firejail config?
      - nextos 2y ago
        I just use the "net none" option. For the rest of the programs, Firejail default profiles are spot on. Alternatively, you can use bwrap --share-net=none emacs.
    - internet_points 2y ago
      Do you use firejail for other things too? Say I'm developing a js project and have to do npm install and run-dev-server or something, would/could you use firejail with that (to avoid npm putting your ssh keys on pastebin due to bad third party js)? Would you firejail the whole bash session? I feel so worried every time I walk into a new ecosystem, and there are new developer tools required. They invariably want me to install things outside their project folder or edit .bashrc or require sudo. It's affecting my sleep. Just running `make` in the wrong folder can start downloading things. It's gotten so bad lately I'm even considering Qubes.

by uludag 2y ago

hollerith 2y ago

I strongly prefer vscode's solution to the current state of affairs in Emacs.

uludag 2y ago
I have no doubt that VSCode has a much less risk of executing code by opening something. Ironically however, it seems that VSCode's extension is the most effective channel to distribute malware in the history of code editors. [1] [2] Not that MELPA couldn't be used to distribute malware either, I just think, as another poster mentioned, these problems are almost more social than technical. [1] https://www.bleepingcomputer.com/news/security/malicious-vscode-extensions-with-millions-of-installs-discovered/ https://www.bleepingcomputer.com/news/security/malicious-vsc... [2] https://arxiv.org/html/2411.07479v1 https://arxiv.org/html/2411.07479v1
- alwayslikethis 2y ago
  If anything, Emacs users are probably much more likely to inspect the code of whatever extension they are using, since with every help page there is a link to the source code. It helps that it's much less popular and so not as big of a target.
  - deleted 2y ago
    [deleted]
dietr1ch 2y ago
Emacs is just too old to be architected with security in mind. It's a great editor, but has baggage that IMHO can't be addressed on the spot. Working on a codebase where you can't (heavily?) break things between any commit imposes such a slow pace that it's not completely unreasonable to start from the ground up and just study what made Emacs great and what didn't work too well. It's surprising how long Emacs has been around and how good of an editor it is. It really makes rewrite attempts such a long stretch that it exhausts the motivation and time out of spirited folks that give it a go, but I think that given how complexity is being modularised and moved out (LSP, DAP, grammars) and newer languages make packaging easier that Emacs will eventually be replaced, definitely without covering everything it can do, but being strong at the average editing session.
- nextos 2y ago
  That's my opinion as well. I run Emacs 24/7 but I do so inside Firejail, with no network access. It's not architected with security in mind and exploits are too easy. The same can be said about the Linux userland. The Unix model of giving plenty of access to resources and any user file to user processes is outdated. I find it frustrating something like Firejail or bwrap is not standard. I don't want a compromised program to have easy access to e.g. my SSH keys.
  - hollerith 2y ago
    >I run Emacs 24/7 but I do so inside Firejail Can you share your Firejail config?
    - nextos 2y ago
      I just use the "net none" option. For the rest of the programs, Firejail default profiles are spot on. Alternatively, you can use bwrap --share-net=none emacs.
  - internet_points 2y ago
    Do you use firejail for other things too? Say I'm developing a js project and have to do npm install and run-dev-server or something, would/could you use firejail with that (to avoid npm putting your ssh keys on pastebin due to bad third party js)? Would you firejail the whole bash session? I feel so worried every time I walk into a new ecosystem, and there are new developer tools required. They invariably want me to install things outside their project folder or edit .bashrc or require sudo. It's affecting my sleep. Just running `make` in the wrong folder can start downloading things. It's gotten so bad lately I'm even considering Qubes.