Comment by dietr1ch
1 year 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.
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.
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.
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 run Emacs 24/7 but I do so inside Firejail
Can you share your Firejail config?
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.
>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.
What about GnuTLS and GnuPG do you think makes them insecure? I think that they offer something unique and that must be factored in; i.e. if you compare them to competitors, you can't compare apples to oranges when making judgments for them. In mind I have projects like Open/Bear/Boring SSL to compare GnuTLS with, and sequoia for gpg. I really like sequoia, but it offers a different product to gnupg.
Emacs is a mosaic of 50 years of computer history, security is not its priority, but I guarantee you that in bug-gnu-emacs any security/network-related patches are most welcome.
Well, how about the fact that gnutls allowed passive cleartext recovery attacks to go unpatched for about 2 years?
How about the fact that GnuPG is predicated upon the web of trust which has been demonstrated not to work, encourages misuse in the form of long-lived identities which discourages key rotation, has no ratchets nor forward secrecy, has multiple internal key parsers, and a littany of vulnerabilities involving authentication and downgrade attacks?
GNU is just organizationally incapable of producing secure code. These tools are not good tools. GnuPG in particular offers absolutely nothing that another single-purpose tool doesn't do better, but for some reason people get emotional and mount all kinds of irrational defenses of it. GPG is not good. It is broken at a fundamental level.
16 replies →
I have heard it said that a problem with GPG is that it does encryption AND signing when you'd ideally have separate tools for those tasks, like, for example, age for encryption.