Emacs doesn't market itself as a sandboxed tool. It is purpose built to give users unrivaled powers. There are obvious consequnces to this. What is more scary is running untrusted js in a browser that has been marketed as sanboxed, but you probably do this all day every day
Agreed. Also, I expect that malicious elisp is relatively rare, while malicious js is probably about half of it.
While I'm trying to sober up people who are panicking I don't mean to downplay the dangers. The op article is quite informative and should be read by all emacs users. While malicious el code is probably rare, the value gained by compromising an emacs user (programmers academics researchers etc) compared to compromising a random js user (everyone) is probably way greater. Also very few people look at emacs security
Could starting $ emacs --daemon, and connecting to another machine using the client act as a kind of sandboxing or it has no benefit whatsoever?
Maybe that could be used as a starting point to implement a security strategy for some not totally trusted packages. It could complicate things, but hopefully not too much.
If you are concerned about security you should not be running arbitrary programs. For example if you have a lots crypto assets, you shouldnt keep your wallet details on the same computer you are running programs you don't trust. However, practicality often forces you to adopt a more yolo approach toward security. What people often dont realise is that emacs is almost an operating system, and installing emacs packages is kinda like insralling .bat or .exe files. To me personally emacs is the single best piece of software ever produced, by a long shot, but it is a good idea to be aware of its powers.
Emacs can infact be great for security. Its code and language are very nice and well documented and if you care to understand the code you are running and you are THAT concerned about security it can be an excellent aid toward peace of mind.
Yeah, but does that mean, (supposing they are different machines), a package is installed on both computers? On the client and the server? It sounds redundant, and pretty strange if and that's indeed what happens. I will read eventually the docs and find out myself, but it's gonna take 2-3 hours to dig out documents.
> if you care to understand the code you are running and you are THAT concerned about security it can be an excellent aid toward peace of mind.
Elisp can be more difficult to review that Rust. It is much more difficult to hide malicious pieces of code, inside a Rust program that in Elisp. Elisp is pretty powerful as many lisps are, but you can write Emacs modules in Rust. See ubolonton's project on github. I tested it at some point and it works.
>if you have a lots crypto assets
If i had crypto assets, (which i don't), then the correct way to organize money units, tokenized pieces of housing, tokenized pieces of cars, a thousandth of a car for example, is to use an identity which can create children identities, and each child identity can be revoked on demand by the root identity or the parent identity. Then you only really have to keep secure the root identity, everything else is revocable.
Dont take it as advice, but I think the deamon will handle the macro business, so in that sense you are connected to a compromised remote machine.
> Elisp can be more difficult to review that Rust.
Im not a rust programmer, so to each their own I guess. To me it is pretty easy to spot weird lisp code while rust is a headache to me. However as far as I know rust also has macros and unsafe options. Im also wary of anything that markets itself as "safe" because overconfidence is enemy of safety
The point about crypto assets is that you dont normaly use an editor to interact with it (or any full blown computation) and security is pretty straighforward. However if you are developing a software product it is less straighforward. You will use an IDE, probably some third packages, etc. Lots of ways something can go wrong