4 ms·

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.
    - nextos 2y ago
      I use Firejail in the terminal as I am also concerned with the things you mentioned. bwrap is also a possibility. For simple usecases, they are not too intrusive. You can easily create a development profile that bans internet access and forbids read access to your important files. Then wrap CLI commands around that, or perhaps even the entire Bash session. It's like a poorman's QubesOS. I also recommend setting up a userspace firewall like Little Snitch or OpenSnitch. Most malware requires Internet access to do harm. Those provide a good last line of defense. It's a shame the Unix model of giving coarse-grained access to user processes has not been patched. It's not that hard and it's a big security issue.

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.
  - nextos 2y ago
    I use Firejail in the terminal as I am also concerned with the things you mentioned. bwrap is also a possibility. For simple usecases, they are not too intrusive. You can easily create a development profile that bans internet access and forbids read access to your important files. Then wrap CLI commands around that, or perhaps even the entire Bash session. It's like a poorman's QubesOS. I also recommend setting up a userspace firewall like Little Snitch or OpenSnitch. Most malware requires Internet access to do harm. Those provide a good last line of defense. It's a shame the Unix model of giving coarse-grained access to user processes has not been patched. It's not that hard and it's a big security issue.