Comment by uludag
1 year 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 .
I strongly prefer vscode's solution to the current state of affairs in Emacs.
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-vsc... [2] https://arxiv.org/html/2411.07479v1
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.
1 reply →
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.
Depending on what you consider Emacs to be, it is either unlikely to be replaced, has already been replaced, or the concept makes no sense.
Emacs is an interactive Lisp environment that just so happens to have everything you need for a programmable text editor. Text editors are a dime a dozen, and Emacs is far from the only programmable one (although I'm not aware of any with the degree of programmability that Emacs offers). You can find alternatives for pretty much all of Emacs' functions, but you'll have a hard time finding it all in one place.
People have been talking about replacing Emacs itself with another interactive Lisp platform for decades (generally based on Scheme or Common Lisp), but it hasn't happened. I doubt it will. As cool an idea as Lem or Climacs or whatever are, they haven't attracted the user and developer base needed to even begin to approach Emacs' level.
And by and large, Emacs users don't care. We're a small enough group these days that no one is likely to target us with serious malware. We blindly trust Elpa and Melpa and the people who commit code there, and so far it hasn't been a problem. Complacent? Certainly, but that's human nature.
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.
4 replies →
>Emacs is just too old to be architected with security in mind.
Bad security is endemic to all GNU projects. gnutls and gnupg come readily to mind, for example. In fact there was an article/blog post making the rounds a few years ago about how the letters "GNU" are an excellent heuristic for broken security models and fatally-flawed crypto.
19 replies →