Long time Emacs Lisp coder here. Here is a summary of the vulnerability described in the OP:
Anyone wishing to inspect an untrusted file of Emacs Lisp code
is likely to use Emacs to do the inspecting, but if
either of the popular packages Flymake and Flycheck is enabled,
merely opening the untrusted file gives the author of the file
the ability to run arbitrary code (because macros are tricky).
Even if an Emacs user avoids Flymake and Flycheck, the standard
emacs facility for "completing" the names of functions and variables
has the same basic vulnerability. Specifically, if the user uses Emacs to open the file, then types the start of the name of a function or variable, then types M-tab (i.e., presses the escape key, then presses the tab key) which attempts to fill in the rest of the name so that user does not have to manually type out the whole name, the arbitrary code is run.
It is clear to me (who was never tempted to use Flymake or Flycheck) what remediation I want: namely I want this "M-tab" functionality (which I have been using and probably most Emacs users have been using) to refrain completely from expanding any macros even
though doing so will prevent it from finding out the names of some of the functions
and variables I might be trying to insert with the result that sometimes I will have to type out the full name of the function or variable, without assistance.
>AFAICT the earliest public discussion about the security implications of Emacs Lisp macros started in August 2018, when Wilfred Hughes noted that code completion can lead to arbitrary code execution via macro-expansion.
The fact that the maintainers have yet to fix this is one more sign added to a list of 5 or 6 other signs that make me want to migrate away from Emacs.
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 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.
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.
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.
>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.
>How about the fact that GnuPG is predicated upon the web of trust
No it is not, the web of trust is one mode of operation out of infinitely many that you can come up with, it's not forced upon the user. It was evangelized for a long time until the keyservers got DOSed. In retrospect obvious, but also gnupg is more-or-less an "activist" project -- big corps and govs are against encryption for the masses by and large. Had it had institutional backing from the beginning (which it never got) it'd have a much more robust model for users to work with.
>encourages misuse in the form of long-lived identities which discourages key rotation
You can automate key rotation with gpg. The long-lived identity argument can be seen as a strength too, short-lived isn't always better.
>a littany of vulnerabilities involving authentication and downgrade attacks?
I'm not aware of these; do you mean that GnuPG is not secure by default in its algorithm list? It chooses compatibility over security, but you're free to change the configuration. I think it's too harsh to say that GnuPG is inadequate because of that.
>GNU is just organizationally incapable of producing secure code.
I don't see why that'd be true, anyone can contribute to GNU so there is nothing inherent about GNU that makes its projects insecure.
>GPG is not good. It is broken at a fundamental level.
Works for me! I use it to sign my git commits and tarball releases, and with gpg-agent I get to authenticate to SSH servers.
This is an anonymous blog, and the author conceals their identity, which is already an issue for me. Let's look at the alternatives to PGP that the blog recommends, I will paraphrase:
1) Sign software with sigstore.dev
The issue here is that you delegate trust to places like GitHub or other OIDC providers. You also have to trust Fulcio and their CAs. <https://docs.sigstore.dev/about/security/> for details. Maybe you don't want to do that, in part because you're not guaranteed that the service will remain free, or perhaps you're more serious about security than GitHub.
1-alt) Sign software with minisign.
Maybe I don't want to use Ed25519. Maybe I want to revoke the signatures. There's many issues one may have with minisign.
2) Signing git tags/commits
Advises to use SSH, no explanation why. Advises Ed25519, why not Ed448? The explanation to not use RSA is by linking to <https://blog.trailofbits.com/2019/07/08/fuck-rsa/>. I will only quote one thing from this article:
>RSA was an important milestone in the development of secure communications, but the last two decades of cryptographic research have rendered it obsolete.
You can't say it is obsolete when it is still in use. I'm not sure what the author(s) mean by "obsolete", but it is not true that RSA is obsolete. (If Ed25519 breaks but RSA doesn't, who will be obsolete?)
3) Sending files between computers
Here it recommends Magic Wormhole. That's shocking to me, I don't understand why it is recommended. Why not rsync? If you look at the 2016 presentation for Magic Wormhole <https://www.lothar.com/~warner/MagicWormhole-PyCon2016.pdf>, the pitch is that it is especially useful when the computers are unrelated. How often is that the case? Rsync is a much better solution for anyone who wants to transfer files between servers they have access to.
4) Encrypting Backups
Here they recommend tarsnap as "the usual recommendation", I've got to say, it's definitely not the usual recommendation.
5) Encrypting Application Data
They say to use Tink or libsodium. Tink has many implementations in each language, (how does that help security?) and libsodium doesn't support RSA, two things on top of my head that may be deal breakers.
6) Encrypting Files
They recommend age; wishful thinking as most people do not use age. In fact most people do not bother encrypting files, and it is not something that is done often. The author likes to talk about footguns, well there's certainly many footguns to file encryption. This is where the most analysis is on this blog article too, but this is a niche case.
7) Private Messaging
It recommends Signal. What about e-mail?
>(Unless you’re legally required to use PGP because of a government regulation… in which case, why do you care about my recommendations if you’re chained by the ankle to your government’s bad technology choices?)
It comes off as know-it-all.
Let me close with this: Cryptography is infamous for debates. It never ends, and many people have ended up with egg on their face for their claims. Tread carefully and don't rely on others too much!
More in keeping with the Unix philosophy of doing one thing and doing it well (GnuPG in particular does a mediocre job of many things), the best move is to replace it with a suite of single purpose tools.
For example, signing commits with minisign or signify.
>For example, signing commits with minisign or signify.
These tools don't work well with git or the git forges, and they do not work at all with fossil. (Obviously signify is a good choice if you're using OpenBSD.) Furthermore they lock you in entirely in their choice of algorithm, Ed25519, which may not be what you want (Why not Ed448?)
As far as adoption goes, and adoption is hard to get going, GnuPG is what is used in Linux the most...
"Github supports GnuPG signatures" does not contradict the statement "GnuPG is trash". I will not engage further, it's obvious you are not interested in honest discussion of the technical merits.
> I will not engage further, it's obvious you are not interested in honest discussion of the technical merits.
Well you are neither, all you do is throw unobjective flames around ("gnupg is trash") and post various claims about bad security without backing them up, implicitly demanding that other people do the leg work of disproving your accusations against the GNU project.
You can add a patch to git to support more signature types than just OpenPGP. You may then be able to move mountains and get GitHub/others to join in the validation. Finally, if you can find bugs/exploits in GnuPG, you should report them and you will definitely get credit and recognition for them. They are not trivial to find.
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.
> 5 or 6 other signs that make me want to migrate away from Emacs.
Sure, Emacs is not without deficiencies. But what are the alternatives? Name one option that can do things in the way that Emacs allows you to? Don't say 'Vim' - as a die-hard vimmer who uses both daily, I can confidently tell you - it may take decades until Vim becomes sufficiently good to replace Emacs for me. And if you say 'VSCode', I'd simply laugh coughing up org-mode structured headings.
sure, if you're looking for something that can perfectly replicate what Emacs does, then you'll never find an alternative... Every alternative has obvious shortcomings, at least on first glance, that you have to get used to.
I have never used Emacs (other than briefly starting it up in the 90s, waiting 5 minutes for it to load on my old 386, just to be completely overwhelmed and closing it again) but I have used other tools that I replaced (sometimes multiple times) over the years. And it has never been "smooth". The first few days are full of compromises until you get into a mode of working "with" the new software instead of "against" it. Then it usually begins to make sense and after a week or two you've in business
Okay, but you know what? During my career as a software developer, I have wasted over a decade "getting used to" things being shitty, passively accepting mediocrity and suboptimal solutions.
Learning Emacs (and Vim too) finally made me realize that I was doing things wrong - I needed to be in charge. As a computer programmer, I should be commanding software, not being constrained by it.
Emacs has granted me that power by acting like glue. I don't turn away from useful software; I do use it. I just do it through Emacs, not instead. With Emacs, I make my own rules and I dictate what makes sense.
Most recent practical example? I just joined a team that uses Jira. Lots of people hate Jira (and for good reasons), in my case, I have no choice. So, instead of complaining how cumbersome and stupid Jira is, I decided to use it from Emacs. But instead of wasting time building a "native" extension, I just delegated things to go-jira - a command line client. Now, I can basically type 'FOO-31415' and Emacs automatically, contextually recognizes it as the 'jira ticket number', despite it being plain text. From that point I can retrieve its summary, turn it into a markdown link, browse the ticket, change its fields and status, etc. While anyone else have to waste their time opening Jira in the browser, I can perfectly do things without losing my focus, directly from my editor. That's working "with" software instead of letting software to fight "against" you.
Been using Emacs for 15 years, and I think you've perfectly captured the spirit of what makes Emacs so compelling in spite of the crazy time investment needed to make it your own. I have never used another piece of software that not only allows you to customize it so deeply but makes you feel like you're the one in control.
I know right? Sometimes it so ridiculous, it's not even funny.
Here's one, totally idiotic example. I use Google Translate directly in Emacs, okay? So, when you enter something like "He was born in 1978", it doesn't translate the date, and that's sensible. But I'm learning a language, I really need to see it e.g. in Spanish like this: "Nació en mil novecientos setenta y ocho", and I didn't want to write every time "He was born in nineteen seventy-eight", so I wrote a tiny function (took me ten minutes) advising google-translate that installs 'number-to-words' npm package and uses it to turn the numbers into words before sending the whole thing to Google Translate API. Totally imbecilic, right? I guess shit ain't no so stupid if thy shit works, yes?
Now, Neovim, VSCode, Jetbrains, and Sublime, they all have similar plugins for translation. I wonder if any experienced user would ever bother with something like that? I bet they just wouldn't. It wouldn't occur to them to even consider that as a minor annoyance. Emacs on the other hand, changes the way you think about efficiency and being in control.
I agree (but at times have spent too much time customizing Emacs because of the emotional appeal of exercising this control over my personal software environment).
Time has to be spent, no matter what: you can either adapt your workflow to match the design of specialized apps, or you can choose to go against the norm and manage it on your own terms.
I vividly remember my own misery when trying to find the most optimal, ideal note-taking solution. I went through Evernote, Workflowy, Google Todos, Google Keep, Todoist, Notion, Trelo, Remember the Milk, Obsidian, and some other options.
On the other hand, I have spent a long time studying and customizing Org-mode. I can say with absolute certainty that the net positive ROI from this effort is far greater than it could ever be with any other option.
"Ignorance is bliss", right? Less tech-savvy people genuinely live in blissful ignorance of the endless possibilities, the ways and the methods available. Programmers are different - they can spot your bullshit right away, "you're holding it wrong" vibes don't sit well with them, you don't tell them "users don't know what they want", they'd get annoyed and will try to find a better way - writing scripts, hacking your app, setting up unconventional keybindings, etc.
Emacs is for programmers, for tinkerers who prefer to deal with computing on their own terms. I know the feeling - some new, shiny app comes out that makes ripples in HN threads, and you'd feel old, cranky, and left out with your not-so-shiny, brutally simple yet efficient Emacs UI, thinking that maybe this is the time when you finally have to move away from it. Then you try that shiny new feature everyone so enthusiastically talks about and think, "Meh, that's it? Is that what they're so excited about? I can't believe now I have to use this shit because everyone else does..." And then a few weeks later, someone builds an Emacs package for it.
I never regret time spent on customizing Emacs because I've gotten to the point where I know exactly how to get the most use out of that exercise. It's nothing but pure, unadulterated pragmatics. The notion that Emacs users waste their time configuring it instead of doing real work is a myth. It's like saying that the cook spends too much time sharpening the blade instead of actual cooking. A great chef knows a great deal about his knives and always keeps them very sharp, but he's not in a knife-sharpening business.
Judging by your profile comments, it looks like you have little clue what any of these words mean, especially the last one, which could be due to your emotionally underdeveloped brain. Before you start spitting your snacks at the screen in rage, let me explain - comments like yours often suggest someone experiencing difficulties with emotional regulation, empathy, and interpersonal relationships. I don't know the source of your irrational anger, but you may want to find someone to talk about it. Modern therapy can drastically change people's lives for the better.
I'm a lot less worried about this than I am about MELPA packages being targeted. But any other editor that incorporates a package manager exposes the same threat surface, and just about all of them are a lot more popular (thus more worth targeting) than Emacs.
Well I use mostly stock emacs. If that's already owned, then I guess I'm screwed. I'm very selective about adding additional packages or using other "uninspected" elisp code.
It looks like adding a defcustom that would disable macro expansion, and basically any attempts to eval the code being edited, should not be a lot of work, or at least doable. Disable it in your config, get a nerfed-down but shields-up elisp editing mode.
Am I missing anything here? E.g. should I expect pieces of C code that handle completion in elisp mode?
> It looks like adding a defcustom that would disable macro expansion, and basically any attempts to eval the code being edited
Probably, yes. „org-babel“ can execute shell code inside an org document but always asks the user before it does. You can disable this if you want to. No big deal. Should totally work like this in elisp-mode, too.
I expect that the entire mode is implemented in elisp-mode.el. It's based on lisp-data-mode, but I don't expect that to handle macros (should check though).
Looking at elisp-completion-at-point and likely deeper into elisp--completion-local-symbols, I'd try to find where macroxpansion occurs, and make it conditional. Same for the explicit emacs-lisp-macroexpand.
I would also search for `(eval ` in general and maybe put it under a buffer-local flag, too, so that you won't press C-x C-e or C-M-x and execute malicious code by mistake, when you know you're working on a piece of malicious code.
Maybe instead of a defcustom, it should rather be a minor elisp-paranoid-mode which would do all kinds of things to prevent execution of the code in the buffer, or the code the buffer refers to, etc.
Doesn’t vim also have some ability, easily abused, to put a script at the top of a file, and it’ll just run when you open the thing?
This seems like a really useful functionality to have in the context where you actually do trust the files, but it is wildly insecure and an unexpected trapdoor, to have simple files executing things when you open them with a simple text editor…
Probably going to add similar protections here? Basically, I'd assume if it is your first time visiting a file, macros won't be expanded during autocompletion.
I dunno. I can see why this functionality might be useful, but I kinda think distros should disable it by default/make it whitelist-only.
I think the implications are really unexpected for “new” users (where “new” could be pretty generously defined, I mean, I know a couple people who use vim IRL, I think they would not expect this… it is the sort of thing you know about if you are somebody who goes online to talk about text editors I think). And these are also the sort of users who are used to seeing shebangs and other line noise at the top of files, not understanding it, and ignoring it.
I think we’re only being protected by the fact that spreading a virus though command-line text editors is… going to result in not a ton of hits.
I'm confused. Per the doc, it is disabled by default? Specifically, the first time it is encountered on a file, it will ask the user if they want to allow it. And they flat out don't ever do things like "eval" during these values.
That's a different potential vulnerability. I knew about that one (and had disabled the running of such scripts). I didn't know about this one till today.
Helping me finish typing the name of a function or variable ("completion") is not the sort of thing I expected (till today) the maintainers of Emacs to be so eager to do that they'd start running code that I never asked to be run.
A common pitfall of IDE integration for dynamic languages is that it tends to execute the code under test to provide contextual completion or may decide to run doctests, etc. This has been/is a problem with editing Ruby code, and perhaps Python code and more too too. I'm unsure if this is a problem editing vimscript or lua with NeoVim with the only non-evidence is that I haven't heard of it.
Good call to prevent macro expansion. Does also no big harm nowadays as there are several other ways to get good auto completion, e.g. copilot. Other than that no need to restrict functionality for power users.
The Church of Vim is always accepting new disciples.
Jokes aside, if you're considering Vi-like editors (and assuming you haven't already done your research -- which by the sounds of it, you may well have):
- I recommend going for Neovim over classic Vim at this point. The first-class Lua support for building out your configs and working with extensions is a big quality-of-life improvement over just VimL, and it's a more portable skill with fewer surprises. As a bonus, this gives you access to a world of shockingly high-quality extensions that require Lua to run.
- If you want a decent starting point before you start tweaking a ton of settings, Spacevim is it. I haven't used it extensively but I've only heard good things.
- I recommend against trying to use Emacs bindings in Vim if you can help it. I used these when I initially moved over (at this point about a decade ago) and they were clunkier than both Emacs's bindings and Vim's native bindings. Learning how to work with Vim's modes is an investment that pays off as quickly as a few days with intense use, or a few weeks with more casual use.
- `vim-arpeggio` (or the native chording support in newer versions of Neovim) is your friend for avoiding `<Esc>`-induced repetitive-strain injury.
Oh, you think people choose Emacs instead of Vim because of keybindings?
Then tell me please, how often do you do your research in Vim, using LaTeX embeddings while taking annotations to a pdf that's rendered in the adjacent window?
How often do you take notes, while watching a YouTube video while controlling the playback, speed and volume from your editor? I can watch the video, while following the transcript karaoke-style, pause, speed-up, mute the video whenever I want (so I can start typing), I can grab the pieces of transcript and ask an LLM to give me explanations, etc.
Do you read RSS in Vim? Are any RSS readers as well-integrated and feature-rich as elfeed.el in Emacs? I honestly doubt it. And it's not a matter of skepticism over the quality of Vim extensions. Emacs has far fewer active users and even fewer of those who build things in Elisp, yet it remains the most integratable thing ever. The thing is - unlike VSCode, Vim, Sublime, and IntelliJ - Emacs allows you to change any given behavior of any function - built-in or third-party - with such great granularity that is simply not possible anywhere else.
What about email? Is there anything close to the level of notmuch, mu4e or gnus? I seriously doubt any vim plugins provide the same level of integration.
Do you manage your Jira (or whatever project management) you do from Vim?
Do you control your browser from Vim? I do it from Emacs and it's very cool.
Can you perform a dynamic search on YouTube, Google, DuckDuckGo, Wikipedia, your browser history and other places while typing the query only once? I do that all the time in Emacs.
So, Emacs is not about keybindings. Because you can change them in a way that no other editor lets you do. In Emacs you can use whatever modal or non-modal editing flavor you want, but that's beyond the point.
> How often do you take notes, while watching a YouTube video while controlling the playback, speed and volume from your editor? I can watch the video, while following the transcript karaoke-style, pause, speed-up, mute the video whenever I want (so I can start typing), I can grab the pieces of transcript and ask an LLM to give me explanations, etc.
Hey, any chance you can expand on how you do this, or just share configs?
Considering the steady stream of CVE's against Vim's C code, security is the last reason to choose Vim. I've often wondered why there were so many Vim CVE's, and meanwhile never really any Emacs CVE's. My thinking has been that it's because so much of Emacs is implemented in Elisp, a memory-safe language, and much more of Vim is implemented in C.
So now there is an Emacs CVE, and it's a big one. But if you're going to jump ship for something more secure, it would be woefully misguided to go for Vim.
Any editor that goes for expressive power and flexibility is going to have security issues sooner or later. If you want safe, you'll need to cut features, pick something simple.
As a schismatic from the Church of Vim, I’m compelled to recommend kakoune here. Unless you’re running in a peculiar legacy platform like Windows or Amiga, the selection oriented editing and smooth Unix integration are a delight.
I've considered it from time to time. The conclusion I keep drawing is that, if I were going to benefit from a selection-oriented editing paradigm, I would use Visual mode more than I do.
The multi-cursors, those I want. But I'm willing to wait for Neovim to get them.
That’s entirely reasonable; I switched in part because I was using visual mode so much. That being said, if you want a more vi-like experience in kakoune, you can always pipe your whole buffer through sed :)
As another fan of Kakoune's model of editing (or model of modal editing), I would recommend Helix. It's a low-config tool that lets you start working without turning many knobs. Supports tree-sitter grammars and language server protocol.
> I recommend against trying to use Emacs bindings in Vim if you can help it
This is fine, I think. Using C-w is more convenient than <Esc>diw. I also find C-a and C-e quite convenient, although you need plugins for these (tpope's vim-rsi is good).
I might be worth starting without them, though, so they learn not to rely on them too much.
That being said, I use home-row mods, which makes Control a lot easier to use than regular keyboards.
Are you saying there can’t be security vulnerabilities in Neovim? [rhetorical question]
As I understand it, the vulnerability is that viewing untrusted elisp code may lead to arbitrary code execution. Personally, I don’t remember a case where I would view elisp code without the intent of running it.
Scary. I saw a tweet the other day from a job seeker who had been sent a repo of seemingly trustworthy code. The sender claimed to be working with a team that was hiring, or something along those lines. Of course, one file deeply nested within the folds of the project contained a block of obfuscated JavaScript designed to grab as much data from the job seeker as possible and transmit it elsewhere. Had the job seeker run the project without reading through it first, they would have been in hot water.
You can imagine some variant of this attack including a carefully designed Emacs Lisp payload, which the unsuspecting and desperate-for-a-job victim might open in Emacs. Surprising that the Emacs maintainers didn't fix it as quickly as you'd hope.
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
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
The whole issue of trusting other peoples code does have a solution besides just not running it: capability based code execution ("Capability-based security" if you want to look it up)
Processes can forfeit the permission to do certain things. similarily you could allow functions to forfeit the permission to call certain functions down the callstack (transitively, even) or only allow a function to be called from certain contexts/functions.
While certainly a (minor) performance hit when done dynamically, it should be possible,
especially when using an interpreted language. I have not yet seen this done in the context of programming languages, which is probably due to how difficult it would be to set a proper scope and get it right. If A is forbidden from deleting files, for example, but the program allows it to send messages to B (perhaps even by user choice), which is allowed to do so, then that is a natural escape hatch unless B is specifically designed to take this into account. Nonetheless, a hybrid system should be possible to achive, which would at least improve the situation by a non-negligible margin.
In the spirit of the original article: Most editor plugins don't need to interact with other processes or the file system directly, and instead could only affect an associated buffer. In this scenario, I believe that it is actually possible to solve this issue. For other applications, such as git integration, the mass of code that would have to be inspected can at least be reduced.
MacOS has lots of "capabilities" stuff now. It's constantly giving me anonymous prompts asking for some such privilege or not, without any explanation as to why it's necessary, what will or will not happen if I do/don't do it.
I just had the joy of kicking off a large crawl across my file system(s), expecting it to take some time, so I kicked it off just before I went to bed. This morning I arrived to a dialog "Terminal would like to access...", which naturally stalled my 3 command pipeline in its tracks, thus eliminating the primary benefit of doing the job overnight in the first place.
The other day, I guess I installed Discord, or updated it, or something. Anyway, Discord was asking for keystrokes from other apps. "Why!?"
Why does my IDE need root access to install?
What happens if I don't let random program crawl my network?
As a carbon based user, "capabilities" are a pain in the neck.
Windows lost this battle decades ago, when every. single. new program required "admin" privs to be installed. Every single one. Heck, I bet Calculator asked for it. To wit we numb users, wanting to just "use the software" said, "yes. Yes. YES! PLEASE MAKE IT STOP!" to the point where you just gave it no second glance at all.
Capabilities look great on paper. They're fine for things like systemd and daemons and "stuff administrator folks" install.
Wouldn't it be sufficient to "just" write a kind of context manager that watches the macro expansion and then looks at each step what's being done and divvies that up into safe and unsafe execution, so that at least the example of the article
doesn't just automatically run? Obviously it's a lot of work depending on how sophisticated you want that to be but you probably don't need to rearchitect much.
For folks that have never poked around in emacs, the specific difficulty will be that the odds are very high that if you are in an emacs lisp file, you are almost certainly going to want to edit what emacs itself is doing.
I'm specifically talking about scenarios such as "you set debug-on-error."
To that end, the proposal would probably be something like "flymake/flycheck" use a child emacs process to query the code, but the user evaluating the code would still be done in the main emacs?
I feel like capability systems are... the right solution to the right problem at the wrong time.
By that I mean, in an ideal world, nefarious code should never end up on my system in the first place. Regardless of whether it gets ran, regardless if whether it is properly sandboxed to avoid damage. At the end of the day, I don't want bad code in my system at all.
"Easier said than done" is why I said "right solution, right problem, wrong time." But it comes at a cost. A rather extreme cost, in some cases. Walled garden app stores. Runtime overhead.
Development overhead. I'm not just a user, I'm also a developer, so these things end up being roadblocks I have to navigate. And I have to navigate them for no reason of my own. I am not trying to steal my users' data. But in a way, I am getting punished for the actions of others.
This feels like a social problem instead of a technical one. Macros and macro expansion are a core language feature. Code analysis tools have to do macro expansion. You can't handicap core language features and tools in the name of safety. If you are doing something potentially dangerous, you just have to take precautions.
Real world analogy: construction sites are dangerous, but you can't outlaw the bulldozer. It is a necessary piece of equipment. The best you can do is take precautions. Hard hats, high visibility clothing, audible warnings, etc.
Largely this problem which is core to Emacs in the sense it literally is "An Elegant Weapon For A More Civilized Time" due to its age. There is no concept of sandboxing anything in Emacs. You do get an alert sometimes when you change Theme's since they have a notion of totally executable code. Maybe a better solution would be to make a subset of elisp that artifacts be coded in which are sandboxed.
(Adding as a very late edit on the above. I didn't mean that this problem cannot exist in other settings, which I can see is what folks probably read me as meaning. I just meant the problem in this overall story is specific to elisp because it is core to emacs.)
Fair, though with the CL/Python/Whatever you would have to have a session started before visiting the file. I suppose with the newer eglot and friends, it could reach out using LSP as soon as you enter a project directory? At that point, I'd assume similar attacks exist in those contexts, too? Maybe protected by some sandboxing in the LSP side?
Well yes, when "code is data", data suddenly becomes very dangerous. This is recurring theme when dealing with Lisps and Emacs especially. For instance, it is also quite common for Emacs packages to save data in the form of ELisp code. When loading the data, it is simply evaluated and boom, your data is loaded. It's a powerful thing, but of course this is a security issue, and this is why we can't have nice things...
It interesting that this vulnerability has not had the flag raised in the wider Lisp community, since it also applies there.
Most of the packages and modules that the Lisp systems have are shipped as source code, and compiled on site. That suggests that innocuous importing of a internet sourced module can wreak havoc on your system just by loading it, you don't even have to run it.
Granted, it's not quite the same as having something like auto-complete drain your bitcoin wallet, but it's close.
Most every other eco system you actually have to run the code itself to be worried about an exploitation (which, mind, in today's world is a low bar, but a bar nonetheless).
When I had the same problem in my language, I disabled all unsafe code to be expanded - IO and calling native functions - in such automatic cases inside an editor. A sandbox.
He also forgot the case of ordinary functions being called in the coda. Similar problem as Office VBA startup code.
Not an Emacs user but for the life of me I don't understand what justification there is for auto-completion to allow any capabilities other than (a) memory allocation (to generate the code), and perhaps (b) reading the filesystem. Neither of which requires arbitrary code. Why in the world is anything else allowed? And what makes this so damn hard to implement after all these years? It would seem trivial to interpret a macro manually, or to just introduce an evaluation mode that can't do anything else, no?
Sorry, I find it hard to care. You have to multiply the damage caused by the prior probability of the event occurring, and my prior of this happening is very very low. There are so many easier ways to attack people (e.g. poison a package in a language they use, or on MELPA for Emacs hackers) that I can't see this particular attack getting any use.
Security is basically a resource allocation problem. There are an infinity of attack vectors, so which ones should one be concerned about? Probably not this one.
It is (should be) well known that macros, lisp ones and even less capables ones from other languages, are problematic for security. I think a good temporary mitigation to this in Emacs is scanning 3rd party .el files for macros. If there is a macro present give trust warning and offer decreased functionality if untrusted
Macros are pretty ubiquitous in lisp. This would result in a trust warning for pretty much every .el file. I think this would go about as well as Windows Vista UAC pop ups or State of California cancer warnings. If everything is dangerous, nothing is.
The qualifying term is 'trusted'. If you are running an application like emacs you damn sure better trust it. It's like running Windows and saying you don't trust it.
AS for macros in lisp, they are not as ubiquitous as it might seem to an outsider. I write lisp professionally. I write one macro a month, if that, and often I rewrite it as a function afterwards. Saying that macros are ubiquitous in lisp is a meme. To most lispers macros are last resort
If I understand this correctly, this exploit only works with macros that evaluate at least one of their arguments, otherwise no code is actually run. These kind of macros are not that common. I guess one possible fix would be to mark these kind of macros as potentially dangerous and do not expand them automatically for things like code completion and such.
When you load a Lisp source code file, each of the forms and that file is read and executed.
You know like pretty much any scripting language.
You don't need a macro to perpetrate damage.
Bash doesn't have macros. yet it's a very bad idea to do this:
wget https://url | bash
Lisp macros execute even when a file is not being executed but only compiled. What that means is that you have to trust a file in order to compile it because by doing so you're running it.
Besides compiling any other tooling which expands macros is vulnerable to execution. As we can see in this article, there our situations when if you're working with list code inside Emacs, it will expand the macros.
If you were going to blindly run the code anyway, that makes no difference. But developers often look at untrusted source code with no intention to run it and not expecting to do anything harmful just by sitting in their editor.
In principle Lisp macros could be sandboxed. The vast majority of macros do not need to do any system access. They just look at their argument code pieces and calculate a new piece of code, without any side effects or accessing anything in the system.
As a former Emacs advocate, I only use Emacs for org-mode and magit these days.
These are still the finest stay-organized and Git UI modules I've ever seen, respectively, and are still enough to make sure I have Emacs on every system I use.
For coding, I've gone over to VS Code (and sometimes Jetbrains).
I did some FOSS hacking as a teenager a quarter-century ago, so learned Emacs, but then ultimately chose a career unrelated to software development. I still use Emacs for anything and everything text-related: email (Gnus), RSS feeds (elfeed), org-mode where I write up both personal TODOs and serious academic research. The keyboard-driven interface is powerful and now muscle-memory. The in-built Lisp environment makes everything nicely extensible, but Emacs as an IDE, as something people have used to create general software projects, is something I rarely think about.
> long term heavy Emacs users are not using it for coding.
That's not true. I have worked in number of teams where Emacs users were the majority. Most of them didn't use Org, some of them never used Magit, yet they've used it for coding.
This sounds like you shouldn't trust untrusted code. The only real attack vector I can see is if something fucks with MELPA packages that a lot of people use I guess.
I'm obligated by tenants of my faith to point out that the best protection for this exploit is use of Vi(m) or NeoVim. You may throw tomatoes as soon as I duck behind this fence, thank you.
Circa 2002-2003, and the LWN comment describing the exact same scope:
"""emacs is the same, if not worse. (See the node File Variables in the info docs.) You get not only to set random buffer-local variables, but also to evaluate arbitrary lisp code. Ouch!"""
Best protection from exploits is to disconnect your computer, shut it down, smash it with a sledgehammer, quit your job and become a florist.
Whenever you folks say "just use Bla-bla instead of Emacs", you don't realize it's not even at the level of comparison between iOS and Android.
Emacs provides unique capabilities that other applications simply cannot match in terms of simplicity and power.
Like take for example Dired. Sure, there are number of vim plugins, but none of them match the full power of Emacs' Dired of treating directories as editable text.
Or take Org-mode's source blocks. You can for example execute a piece of javascript, then pipe the result into another block in python, then the results of that into sql and finally output it as a chart.
Or you can use source blocks for literate programming. I use them for managing my dotfiles - my entire system is almost immutable, not at the same level of Nix, but still very nice.
Or take an Emacs package called consult-omni - you can type a search query once and it dynamically dispatches queries to Google, YouTube, Wikipedia, your browser history and other places, aggregating the results in one place. Crazy thing is that the package builts on top of another package which itself uses the built-in functions of Emacs.
The power comes from ability to precisely change a behavior of any given function - built-in or a third party - that precision is just impossible in Vim, VSCode or IntelliJ - in Emacs, you can change specific point of any given function without having to rewrite it.
It's not a matter of "faith" as you put it. People who choose Emacs don't do that because of some dogmas, beliefs or folklore. Emacs has earned its reputation as the most extensible software for sound technical reasons. Naturally, any powerful tool can be wielded for both constructive and destructive purposes. But you can't just suggest replacing a Caterpillar 797F Mining Truck with a electric scooter because of 'security concerns' - what am I supposed to do with my 400-ton payload of customizations?
I'm obligated as part of my faith to point out that nano has none of these issues, as I understand that Vim will still execute arbitrary code in some circumstances
you're kidding but as an evil-mode user my first thought was "okay, inspect untrusted elisp in vim before opening it in emacs, got it"
Thanks for downvoting! I'm not sure why that isn't a valid approach, but then, I've never understood why people have a competition between a text editor and a Lisp machine that has an implementation of that text editor in it
Long time Emacs Lisp coder here. Here is a summary of the vulnerability described in the OP:
Anyone wishing to inspect an untrusted file of Emacs Lisp code is likely to use Emacs to do the inspecting, but if either of the popular packages Flymake and Flycheck is enabled, merely opening the untrusted file gives the author of the file the ability to run arbitrary code (because macros are tricky). Even if an Emacs user avoids Flymake and Flycheck, the standard emacs facility for "completing" the names of functions and variables has the same basic vulnerability. Specifically, if the user uses Emacs to open the file, then types the start of the name of a function or variable, then types M-tab (i.e., presses the escape key, then presses the tab key) which attempts to fill in the rest of the name so that user does not have to manually type out the whole name, the arbitrary code is run.
It is clear to me (who was never tempted to use Flymake or Flycheck) what remediation I want: namely I want this "M-tab" functionality (which I have been using and probably most Emacs users have been using) to refrain completely from expanding any macros even though doing so will prevent it from finding out the names of some of the functions and variables I might be trying to insert with the result that sometimes I will have to type out the full name of the function or variable, without assistance.
>AFAICT the earliest public discussion about the security implications of Emacs Lisp macros started in August 2018, when Wilfred Hughes noted that code completion can lead to arbitrary code execution via macro-expansion.
The fact that the maintainers have yet to fix this is one more sign added to a list of 5 or 6 other signs that make me want to migrate away from Emacs.
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.
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.
>Well, how about the fact that gnutls allowed passive cleartext recovery attacks to go unpatched for about 2 years?
They patched it when they became aware of it in <https://gitlab.com/gnutls/gnutls/-/issues/1011>, it was not "allowed" to go unpatched.
>How about the fact that GnuPG is predicated upon the web of trust
No it is not, the web of trust is one mode of operation out of infinitely many that you can come up with, it's not forced upon the user. It was evangelized for a long time until the keyservers got DOSed. In retrospect obvious, but also gnupg is more-or-less an "activist" project -- big corps and govs are against encryption for the masses by and large. Had it had institutional backing from the beginning (which it never got) it'd have a much more robust model for users to work with.
>encourages misuse in the form of long-lived identities which discourages key rotation
You can automate key rotation with gpg. The long-lived identity argument can be seen as a strength too, short-lived isn't always better.
>a littany of vulnerabilities involving authentication and downgrade attacks?
I'm not aware of these; do you mean that GnuPG is not secure by default in its algorithm list? It chooses compatibility over security, but you're free to change the configuration. I think it's too harsh to say that GnuPG is inadequate because of that.
>GNU is just organizationally incapable of producing secure code.
I don't see why that'd be true, anyone can contribute to GNU so there is nothing inherent about GNU that makes its projects insecure.
>GPG is not good. It is broken at a fundamental level.
Works for me! I use it to sign my git commits and tarball releases, and with gpg-agent I get to authenticate to SSH servers.
>Works for me!
Hey, so long as you're cognizant of the fact that everyone credible thinks GPG is at best a security LARP, do what you feel is best.
What better options are there, if you're aware of these weaknesses i'm sure you're aware of better options.
https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/
This is an anonymous blog, and the author conceals their identity, which is already an issue for me. Let's look at the alternatives to PGP that the blog recommends, I will paraphrase:
1) Sign software with sigstore.dev
The issue here is that you delegate trust to places like GitHub or other OIDC providers. You also have to trust Fulcio and their CAs. <https://docs.sigstore.dev/about/security/> for details. Maybe you don't want to do that, in part because you're not guaranteed that the service will remain free, or perhaps you're more serious about security than GitHub.
1-alt) Sign software with minisign.
Maybe I don't want to use Ed25519. Maybe I want to revoke the signatures. There's many issues one may have with minisign.
2) Signing git tags/commits
Advises to use SSH, no explanation why. Advises Ed25519, why not Ed448? The explanation to not use RSA is by linking to <https://blog.trailofbits.com/2019/07/08/fuck-rsa/>. I will only quote one thing from this article:
>RSA was an important milestone in the development of secure communications, but the last two decades of cryptographic research have rendered it obsolete.
You can't say it is obsolete when it is still in use. I'm not sure what the author(s) mean by "obsolete", but it is not true that RSA is obsolete. (If Ed25519 breaks but RSA doesn't, who will be obsolete?)
3) Sending files between computers
Here it recommends Magic Wormhole. That's shocking to me, I don't understand why it is recommended. Why not rsync? If you look at the 2016 presentation for Magic Wormhole <https://www.lothar.com/~warner/MagicWormhole-PyCon2016.pdf>, the pitch is that it is especially useful when the computers are unrelated. How often is that the case? Rsync is a much better solution for anyone who wants to transfer files between servers they have access to.
4) Encrypting Backups
Here they recommend tarsnap as "the usual recommendation", I've got to say, it's definitely not the usual recommendation.
5) Encrypting Application Data
They say to use Tink or libsodium. Tink has many implementations in each language, (how does that help security?) and libsodium doesn't support RSA, two things on top of my head that may be deal breakers.
6) Encrypting Files
They recommend age; wishful thinking as most people do not use age. In fact most people do not bother encrypting files, and it is not something that is done often. The author likes to talk about footguns, well there's certainly many footguns to file encryption. This is where the most analysis is on this blog article too, but this is a niche case.
7) Private Messaging
It recommends Signal. What about e-mail?
>(Unless you’re legally required to use PGP because of a government regulation… in which case, why do you care about my recommendations if you’re chained by the ankle to your government’s bad technology choices?)
It comes off as know-it-all.
Let me close with this: Cryptography is infamous for debates. It never ends, and many people have ended up with egg on their face for their claims. Tread carefully and don't rely on others too much!
More in keeping with the Unix philosophy of doing one thing and doing it well (GnuPG in particular does a mediocre job of many things), the best move is to replace it with a suite of single purpose tools.
For example, signing commits with minisign or signify.
>For example, signing commits with minisign or signify.
These tools don't work well with git or the git forges, and they do not work at all with fossil. (Obviously signify is a good choice if you're using OpenBSD.) Furthermore they lock you in entirely in their choice of algorithm, Ed25519, which may not be what you want (Why not Ed448?)
As far as adoption goes, and adoption is hard to get going, GnuPG is what is used in Linux the most...
"Github supports GnuPG signatures" does not contradict the statement "GnuPG is trash". I will not engage further, it's obvious you are not interested in honest discussion of the technical merits.
> I will not engage further, it's obvious you are not interested in honest discussion of the technical merits.
Well you are neither, all you do is throw unobjective flames around ("gnupg is trash") and post various claims about bad security without backing them up, implicitly demanding that other people do the leg work of disproving your accusations against the GNU project.
Are you working for Apple by any chance?
>Are you working for Apple by any chance?
No, my background is in aerospace and I'm currently in grad school planning to pivot into a different field.
The issue is mostly with git itself, e.g. take a look at
to see something like: You can view an example of the structure of this ascii-armored signature here <https://cirw.in/gpg-decoder/#-----BEGIN%20PGP%20SIGNATURE---...>.You can add a patch to git to support more signature types than just OpenPGP. You may then be able to move mountains and get GitHub/others to join in the validation. Finally, if you can find bugs/exploits in GnuPG, you should report them and you will definitely get credit and recognition for them. They are not trivial to find.
Git has supported SSH-based signatures for a while now, including those backed by FIDO hardware keys.
FIDO would be for authentication, not signing. It also supports SSH (and X.509, see <https://git-scm.com/docs/gitformat-signature>) but it does not support minisign or signify. There's a git module for signify, <https://leahneukirchen.org/dotfiles/bin/git-signify> but don't count on it being widely supported.
What was the CVE for that cleartext downgrade attack ?
For gnutls? I believe it was this one: https://nvd.nist.gov/vuln/detail/CVE-2020-13777
It was not a "downgrade attack", it was passive cleartext recovery.
Ah, my mistake, thats why I couldn't find it. Thanks for the link.
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.
> 5 or 6 other signs that make me want to migrate away from Emacs.
Sure, Emacs is not without deficiencies. But what are the alternatives? Name one option that can do things in the way that Emacs allows you to? Don't say 'Vim' - as a die-hard vimmer who uses both daily, I can confidently tell you - it may take decades until Vim becomes sufficiently good to replace Emacs for me. And if you say 'VSCode', I'd simply laugh coughing up org-mode structured headings.
sure, if you're looking for something that can perfectly replicate what Emacs does, then you'll never find an alternative... Every alternative has obvious shortcomings, at least on first glance, that you have to get used to.
I have never used Emacs (other than briefly starting it up in the 90s, waiting 5 minutes for it to load on my old 386, just to be completely overwhelmed and closing it again) but I have used other tools that I replaced (sometimes multiple times) over the years. And it has never been "smooth". The first few days are full of compromises until you get into a mode of working "with" the new software instead of "against" it. Then it usually begins to make sense and after a week or two you've in business
Okay, but you know what? During my career as a software developer, I have wasted over a decade "getting used to" things being shitty, passively accepting mediocrity and suboptimal solutions.
Learning Emacs (and Vim too) finally made me realize that I was doing things wrong - I needed to be in charge. As a computer programmer, I should be commanding software, not being constrained by it.
Emacs has granted me that power by acting like glue. I don't turn away from useful software; I do use it. I just do it through Emacs, not instead. With Emacs, I make my own rules and I dictate what makes sense.
Most recent practical example? I just joined a team that uses Jira. Lots of people hate Jira (and for good reasons), in my case, I have no choice. So, instead of complaining how cumbersome and stupid Jira is, I decided to use it from Emacs. But instead of wasting time building a "native" extension, I just delegated things to go-jira - a command line client. Now, I can basically type 'FOO-31415' and Emacs automatically, contextually recognizes it as the 'jira ticket number', despite it being plain text. From that point I can retrieve its summary, turn it into a markdown link, browse the ticket, change its fields and status, etc. While anyone else have to waste their time opening Jira in the browser, I can perfectly do things without losing my focus, directly from my editor. That's working "with" software instead of letting software to fight "against" you.
Been using Emacs for 15 years, and I think you've perfectly captured the spirit of what makes Emacs so compelling in spite of the crazy time investment needed to make it your own. I have never used another piece of software that not only allows you to customize it so deeply but makes you feel like you're the one in control.
> you feel like you're the one in control.
I know right? Sometimes it so ridiculous, it's not even funny. Here's one, totally idiotic example. I use Google Translate directly in Emacs, okay? So, when you enter something like "He was born in 1978", it doesn't translate the date, and that's sensible. But I'm learning a language, I really need to see it e.g. in Spanish like this: "Nació en mil novecientos setenta y ocho", and I didn't want to write every time "He was born in nineteen seventy-eight", so I wrote a tiny function (took me ten minutes) advising google-translate that installs 'number-to-words' npm package and uses it to turn the numbers into words before sending the whole thing to Google Translate API. Totally imbecilic, right? I guess shit ain't no so stupid if thy shit works, yes?
Now, Neovim, VSCode, Jetbrains, and Sublime, they all have similar plugins for translation. I wonder if any experienced user would ever bother with something like that? I bet they just wouldn't. It wouldn't occur to them to even consider that as a minor annoyance. Emacs on the other hand, changes the way you think about efficiency and being in control.
I agree (but at times have spent too much time customizing Emacs because of the emotional appeal of exercising this control over my personal software environment).
> spent too much time
Time has to be spent, no matter what: you can either adapt your workflow to match the design of specialized apps, or you can choose to go against the norm and manage it on your own terms.
I vividly remember my own misery when trying to find the most optimal, ideal note-taking solution. I went through Evernote, Workflowy, Google Todos, Google Keep, Todoist, Notion, Trelo, Remember the Milk, Obsidian, and some other options.
On the other hand, I have spent a long time studying and customizing Org-mode. I can say with absolute certainty that the net positive ROI from this effort is far greater than it could ever be with any other option.
"Ignorance is bliss", right? Less tech-savvy people genuinely live in blissful ignorance of the endless possibilities, the ways and the methods available. Programmers are different - they can spot your bullshit right away, "you're holding it wrong" vibes don't sit well with them, you don't tell them "users don't know what they want", they'd get annoyed and will try to find a better way - writing scripts, hacking your app, setting up unconventional keybindings, etc.
Emacs is for programmers, for tinkerers who prefer to deal with computing on their own terms. I know the feeling - some new, shiny app comes out that makes ripples in HN threads, and you'd feel old, cranky, and left out with your not-so-shiny, brutally simple yet efficient Emacs UI, thinking that maybe this is the time when you finally have to move away from it. Then you try that shiny new feature everyone so enthusiastically talks about and think, "Meh, that's it? Is that what they're so excited about? I can't believe now I have to use this shit because everyone else does..." And then a few weeks later, someone builds an Emacs package for it.
I never regret time spent on customizing Emacs because I've gotten to the point where I know exactly how to get the most use out of that exercise. It's nothing but pure, unadulterated pragmatics. The notion that Emacs users waste their time configuring it instead of doing real work is a myth. It's like saying that the cook spends too much time sharpening the blade instead of actual cooking. A great chef knows a great deal about his knives and always keeps them very sharp, but he's not in a knife-sharpening business.
Hyping vaporware is not software development.
Judging by your profile comments, it looks like you have little clue what any of these words mean, especially the last one, which could be due to your emotionally underdeveloped brain. Before you start spitting your snacks at the screen in rage, let me explain - comments like yours often suggest someone experiencing difficulties with emotional regulation, empathy, and interpersonal relationships. I don't know the source of your irrational anger, but you may want to find someone to talk about it. Modern therapy can drastically change people's lives for the better.
I'm a lot less worried about this than I am about MELPA packages being targeted. But any other editor that incorporates a package manager exposes the same threat surface, and just about all of them are a lot more popular (thus more worth targeting) than Emacs.
Yes, it boils down to "be careful with untrusted code" no matter where it comes from. This is certainly not unique to emacs.
I'm starting to get "return to notepad++" vibes from HN today.
Well I use mostly stock emacs. If that's already owned, then I guess I'm screwed. I'm very selective about adding additional packages or using other "uninspected" elisp code.
It looks like adding a defcustom that would disable macro expansion, and basically any attempts to eval the code being edited, should not be a lot of work, or at least doable. Disable it in your config, get a nerfed-down but shields-up elisp editing mode.
Am I missing anything here? E.g. should I expect pieces of C code that handle completion in elisp mode?
> It looks like adding a defcustom that would disable macro expansion, and basically any attempts to eval the code being edited
Probably, yes. „org-babel“ can execute shell code inside an org document but always asks the user before it does. You can disable this if you want to. No big deal. Should totally work like this in elisp-mode, too.
Would you mind explaining how you could do this?
I expect that the entire mode is implemented in elisp-mode.el. It's based on lisp-data-mode, but I don't expect that to handle macros (should check though).
Looking at elisp-completion-at-point and likely deeper into elisp--completion-local-symbols, I'd try to find where macroxpansion occurs, and make it conditional. Same for the explicit emacs-lisp-macroexpand.
I would also search for `(eval ` in general and maybe put it under a buffer-local flag, too, so that you won't press C-x C-e or C-M-x and execute malicious code by mistake, when you know you're working on a piece of malicious code.
Maybe instead of a defcustom, it should rather be a minor elisp-paranoid-mode which would do all kinds of things to prevent execution of the code in the buffer, or the code the buffer refers to, etc.
You could also macroexpand in a sandbox, e.g. via LSP.
That would involve a rewrite because the way it is now, the relevant code does not use LSP.
Okay, but software is infinitely malleable
Doesn’t vim also have some ability, easily abused, to put a script at the top of a file, and it’ll just run when you open the thing?
This seems like a really useful functionality to have in the context where you actually do trust the files, but it is wildly insecure and an unexpected trapdoor, to have simple files executing things when you open them with a simple text editor…
Emacs has that, too. There are protections in that case, though. See: https://www.gnu.org/software/emacs/manual/html_node/emacs/Sa...
Probably going to add similar protections here? Basically, I'd assume if it is your first time visiting a file, macros won't be expanded during autocompletion.
I dunno. I can see why this functionality might be useful, but I kinda think distros should disable it by default/make it whitelist-only.
I think the implications are really unexpected for “new” users (where “new” could be pretty generously defined, I mean, I know a couple people who use vim IRL, I think they would not expect this… it is the sort of thing you know about if you are somebody who goes online to talk about text editors I think). And these are also the sort of users who are used to seeing shebangs and other line noise at the top of files, not understanding it, and ignoring it.
I think we’re only being protected by the fact that spreading a virus though command-line text editors is… going to result in not a ton of hits.
I'm confused. Per the doc, it is disabled by default? Specifically, the first time it is encountered on a file, it will ask the user if they want to allow it. And they flat out don't ever do things like "eval" during these values.
That's a different potential vulnerability. I knew about that one (and had disabled the running of such scripts). I didn't know about this one till today.
Helping me finish typing the name of a function or variable ("completion") is not the sort of thing I expected (till today) the maintainers of Emacs to be so eager to do that they'd start running code that I never asked to be run.
It's that Lisp data is code, code is data thing.
No, it is not.
A common pitfall of IDE integration for dynamic languages is that it tends to execute the code under test to provide contextual completion or may decide to run doctests, etc. This has been/is a problem with editing Ruby code, and perhaps Python code and more too too. I'm unsure if this is a problem editing vimscript or lua with NeoVim with the only non-evidence is that I haven't heard of it.
What are the other 5, out of curiosity?
Good call to prevent macro expansion. Does also no big harm nowadays as there are several other ways to get good auto completion, e.g. copilot. Other than that no need to restrict functionality for power users.
The Church of Vim is always accepting new disciples.
Jokes aside, if you're considering Vi-like editors (and assuming you haven't already done your research -- which by the sounds of it, you may well have):
- I recommend going for Neovim over classic Vim at this point. The first-class Lua support for building out your configs and working with extensions is a big quality-of-life improvement over just VimL, and it's a more portable skill with fewer surprises. As a bonus, this gives you access to a world of shockingly high-quality extensions that require Lua to run.
- If you want a decent starting point before you start tweaking a ton of settings, Spacevim is it. I haven't used it extensively but I've only heard good things.
- I recommend against trying to use Emacs bindings in Vim if you can help it. I used these when I initially moved over (at this point about a decade ago) and they were clunkier than both Emacs's bindings and Vim's native bindings. Learning how to work with Vim's modes is an investment that pays off as quickly as a few days with intense use, or a few weeks with more casual use.
- `vim-arpeggio` (or the native chording support in newer versions of Neovim) is your friend for avoiding `<Esc>`-induced repetitive-strain injury.
Oh, you think people choose Emacs instead of Vim because of keybindings?
Then tell me please, how often do you do your research in Vim, using LaTeX embeddings while taking annotations to a pdf that's rendered in the adjacent window?
How often do you take notes, while watching a YouTube video while controlling the playback, speed and volume from your editor? I can watch the video, while following the transcript karaoke-style, pause, speed-up, mute the video whenever I want (so I can start typing), I can grab the pieces of transcript and ask an LLM to give me explanations, etc.
Do you read RSS in Vim? Are any RSS readers as well-integrated and feature-rich as elfeed.el in Emacs? I honestly doubt it. And it's not a matter of skepticism over the quality of Vim extensions. Emacs has far fewer active users and even fewer of those who build things in Elisp, yet it remains the most integratable thing ever. The thing is - unlike VSCode, Vim, Sublime, and IntelliJ - Emacs allows you to change any given behavior of any function - built-in or third-party - with such great granularity that is simply not possible anywhere else.
What about email? Is there anything close to the level of notmuch, mu4e or gnus? I seriously doubt any vim plugins provide the same level of integration.
Do you manage your Jira (or whatever project management) you do from Vim?
Do you control your browser from Vim? I do it from Emacs and it's very cool.
Can you perform a dynamic search on YouTube, Google, DuckDuckGo, Wikipedia, your browser history and other places while typing the query only once? I do that all the time in Emacs.
So, Emacs is not about keybindings. Because you can change them in a way that no other editor lets you do. In Emacs you can use whatever modal or non-modal editing flavor you want, but that's beyond the point.
> How often do you take notes, while watching a YouTube video while controlling the playback, speed and volume from your editor? I can watch the video, while following the transcript karaoke-style, pause, speed-up, mute the video whenever I want (so I can start typing), I can grab the pieces of transcript and ask an LLM to give me explanations, etc.
Hey, any chance you can expand on how you do this, or just share configs?
Thanks!
Considering the steady stream of CVE's against Vim's C code, security is the last reason to choose Vim. I've often wondered why there were so many Vim CVE's, and meanwhile never really any Emacs CVE's. My thinking has been that it's because so much of Emacs is implemented in Elisp, a memory-safe language, and much more of Vim is implemented in C.
So now there is an Emacs CVE, and it's a big one. But if you're going to jump ship for something more secure, it would be woefully misguided to go for Vim.
Any editor that goes for expressive power and flexibility is going to have security issues sooner or later. If you want safe, you'll need to cut features, pick something simple.
As a schismatic from the Church of Vim, I’m compelled to recommend kakoune here. Unless you’re running in a peculiar legacy platform like Windows or Amiga, the selection oriented editing and smooth Unix integration are a delight.
I've considered it from time to time. The conclusion I keep drawing is that, if I were going to benefit from a selection-oriented editing paradigm, I would use Visual mode more than I do.
The multi-cursors, those I want. But I'm willing to wait for Neovim to get them.
That’s entirely reasonable; I switched in part because I was using visual mode so much. That being said, if you want a more vi-like experience in kakoune, you can always pipe your whole buffer through sed :)
As another fan of Kakoune's model of editing (or model of modal editing), I would recommend Helix. It's a low-config tool that lets you start working without turning many knobs. Supports tree-sitter grammars and language server protocol.
I haven't heard of either Kakoune or Helix, but I'm buried pretty deep in my own opinionated config.
As far as I'm concerned, the more readymade options, the better. Thanks to you and sevensor for adding recommendations!
> I recommend against trying to use Emacs bindings in Vim if you can help it
This is fine, I think. Using C-w is more convenient than <Esc>diw. I also find C-a and C-e quite convenient, although you need plugins for these (tpope's vim-rsi is good).
I might be worth starting without them, though, so they learn not to rely on them too much.
That being said, I use home-row mods, which makes Control a lot easier to use than regular keyboards.
Spacevim? Emacs bindings in vim? Heresy!
Spacemacs defaults to vim bindings and it's easily my favorite editor, while saving you from (some of) the endless config tweaking.
Are you saying there can’t be security vulnerabilities in Neovim? [rhetorical question]
As I understand it, the vulnerability is that viewing untrusted elisp code may lead to arbitrary code execution. Personally, I don’t remember a case where I would view elisp code without the intent of running it.
Scary. I saw a tweet the other day from a job seeker who had been sent a repo of seemingly trustworthy code. The sender claimed to be working with a team that was hiring, or something along those lines. Of course, one file deeply nested within the folds of the project contained a block of obfuscated JavaScript designed to grab as much data from the job seeker as possible and transmit it elsewhere. Had the job seeker run the project without reading through it first, they would have been in hot water.
You can imagine some variant of this attack including a carefully designed Emacs Lisp payload, which the unsuspecting and desperate-for-a-job victim might open in Emacs. Surprising that the Emacs maintainers didn't fix it as quickly as you'd hope.
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
The whole issue of trusting other peoples code does have a solution besides just not running it: capability based code execution ("Capability-based security" if you want to look it up)
Processes can forfeit the permission to do certain things. similarily you could allow functions to forfeit the permission to call certain functions down the callstack (transitively, even) or only allow a function to be called from certain contexts/functions.
While certainly a (minor) performance hit when done dynamically, it should be possible, especially when using an interpreted language. I have not yet seen this done in the context of programming languages, which is probably due to how difficult it would be to set a proper scope and get it right. If A is forbidden from deleting files, for example, but the program allows it to send messages to B (perhaps even by user choice), which is allowed to do so, then that is a natural escape hatch unless B is specifically designed to take this into account. Nonetheless, a hybrid system should be possible to achive, which would at least improve the situation by a non-negligible margin.
In the spirit of the original article: Most editor plugins don't need to interact with other processes or the file system directly, and instead could only affect an associated buffer. In this scenario, I believe that it is actually possible to solve this issue. For other applications, such as git integration, the mass of code that would have to be inspected can at least be reduced.
MacOS has lots of "capabilities" stuff now. It's constantly giving me anonymous prompts asking for some such privilege or not, without any explanation as to why it's necessary, what will or will not happen if I do/don't do it.
I just had the joy of kicking off a large crawl across my file system(s), expecting it to take some time, so I kicked it off just before I went to bed. This morning I arrived to a dialog "Terminal would like to access...", which naturally stalled my 3 command pipeline in its tracks, thus eliminating the primary benefit of doing the job overnight in the first place.
The other day, I guess I installed Discord, or updated it, or something. Anyway, Discord was asking for keystrokes from other apps. "Why!?"
Why does my IDE need root access to install?
What happens if I don't let random program crawl my network?
As a carbon based user, "capabilities" are a pain in the neck.
Windows lost this battle decades ago, when every. single. new program required "admin" privs to be installed. Every single one. Heck, I bet Calculator asked for it. To wit we numb users, wanting to just "use the software" said, "yes. Yes. YES! PLEASE MAKE IT STOP!" to the point where you just gave it no second glance at all.
Capabilities look great on paper. They're fine for things like systemd and daemons and "stuff administrator folks" install.
For human beings, not so much.
The problem here is that Emacs is the Elisp interpreter. They are the same thing.
Emacs would have to start another process for Elisp analysis and code completion. That would be a massive reachitecture of the system.
Wouldn't it be sufficient to "just" write a kind of context manager that watches the macro expansion and then looks at each step what's being done and divvies that up into safe and unsafe execution, so that at least the example of the article
doesn't just automatically run? Obviously it's a lot of work depending on how sophisticated you want that to be but you probably don't need to rearchitect much.For folks that have never poked around in emacs, the specific difficulty will be that the odds are very high that if you are in an emacs lisp file, you are almost certainly going to want to edit what emacs itself is doing.
I'm specifically talking about scenarios such as "you set debug-on-error."
To that end, the proposal would probably be something like "flymake/flycheck" use a child emacs process to query the code, but the user evaluating the code would still be done in the main emacs?
I feel like capability systems are... the right solution to the right problem at the wrong time.
By that I mean, in an ideal world, nefarious code should never end up on my system in the first place. Regardless of whether it gets ran, regardless if whether it is properly sandboxed to avoid damage. At the end of the day, I don't want bad code in my system at all.
"Easier said than done" is why I said "right solution, right problem, wrong time." But it comes at a cost. A rather extreme cost, in some cases. Walled garden app stores. Runtime overhead.
Development overhead. I'm not just a user, I'm also a developer, so these things end up being roadblocks I have to navigate. And I have to navigate them for no reason of my own. I am not trying to steal my users' data. But in a way, I am getting punished for the actions of others.
Anyway. No solutions here.
This feels like a social problem instead of a technical one. Macros and macro expansion are a core language feature. Code analysis tools have to do macro expansion. You can't handicap core language features and tools in the name of safety. If you are doing something potentially dangerous, you just have to take precautions.
Real world analogy: construction sites are dangerous, but you can't outlaw the bulldozer. It is a necessary piece of equipment. The best you can do is take precautions. Hard hats, high visibility clothing, audible warnings, etc.
Largely this problem which is core to Emacs in the sense it literally is "An Elegant Weapon For A More Civilized Time" due to its age. There is no concept of sandboxing anything in Emacs. You do get an alert sometimes when you change Theme's since they have a notion of totally executable code. Maybe a better solution would be to make a subset of elisp that artifacts be coded in which are sandboxed.
No sandboxing is not a bug, it is the feature that makes emacs into elisp platform, and not just another editor that has defined API for extensions.
This problem is specific to elisp evaluation. It is rare that you would want to work in elisp code and not be modifying your currently running emacs.
If you are working on code for any other language, it is probably using an LSP or other form of child processes, right?
(Adding as a very late edit on the above. I didn't mean that this problem cannot exist in other settings, which I can see is what folks probably read me as meaning. I just meant the problem in this overall story is specific to elisp because it is core to emacs.)
Well I wouldn't say any other language. Common Lisp for example you have a currently running lisp instance that you are modifying.
You can pretty easily set up Emacs to work that way for any language with a REPL.
Fair, though with the CL/Python/Whatever you would have to have a session started before visiting the file. I suppose with the newer eglot and friends, it could reach out using LSP as soon as you enter a project directory? At that point, I'd assume similar attacks exist in those contexts, too? Maybe protected by some sandboxing in the LSP side?
Bulldozers also come with keys that stop random people walking up and turning them on though
And a big enough plane does not stop random people from walking up and turning them on. I don't think this analogy fits here.
Well yes, when "code is data", data suddenly becomes very dangerous. This is recurring theme when dealing with Lisps and Emacs especially. For instance, it is also quite common for Emacs packages to save data in the form of ELisp code. When loading the data, it is simply evaluated and boom, your data is loaded. It's a powerful thing, but of course this is a security issue, and this is why we can't have nice things...
How would this work?
I get no printout when doing C-M-i with the cursor after "mac".Edit: OK. As per the mailing list. I guess it is a feature then.
It interesting that this vulnerability has not had the flag raised in the wider Lisp community, since it also applies there.
Most of the packages and modules that the Lisp systems have are shipped as source code, and compiled on site. That suggests that innocuous importing of a internet sourced module can wreak havoc on your system just by loading it, you don't even have to run it.
Granted, it's not quite the same as having something like auto-complete drain your bitcoin wallet, but it's close.
Most every other eco system you actually have to run the code itself to be worried about an exploitation (which, mind, in today's world is a low bar, but a bar nonetheless).
I think you can just load (require ?) a python module and not run it and it will execute the python code.
I don't think that this is exclusive to python either.
Various modes already prompt if one wishes to respect file-local settings; I imagine that the fix here is similar.
I consider this a feature and I know how to avoid the fix so thanks for the heads up.
When I had the same problem in my language, I disabled all unsafe code to be expanded - IO and calling native functions - in such automatic cases inside an editor. A sandbox.
He also forgot the case of ordinary functions being called in the coda. Similar problem as Office VBA startup code.
Not an Emacs user but for the life of me I don't understand what justification there is for auto-completion to allow any capabilities other than (a) memory allocation (to generate the code), and perhaps (b) reading the filesystem. Neither of which requires arbitrary code. Why in the world is anything else allowed? And what makes this so damn hard to implement after all these years? It would seem trivial to interpret a macro manually, or to just introduce an evaluation mode that can't do anything else, no?
I've been very very reluctant to install third-party extensions to Jetbrains, VScode, and Emacs for just this sort of problem. And it sucks.
Me, too, but the completion-at-point (M-tab) implicated in the OP is part of core Emacs.
Sorry, I find it hard to care. You have to multiply the damage caused by the prior probability of the event occurring, and my prior of this happening is very very low. There are so many easier ways to attack people (e.g. poison a package in a language they use, or on MELPA for Emacs hackers) that I can't see this particular attack getting any use.
Security is basically a resource allocation problem. There are an infinity of attack vectors, so which ones should one be concerned about? Probably not this one.
It is (should be) well known that macros, lisp ones and even less capables ones from other languages, are problematic for security. I think a good temporary mitigation to this in Emacs is scanning 3rd party .el files for macros. If there is a macro present give trust warning and offer decreased functionality if untrusted
Macros are pretty ubiquitous in lisp. This would result in a trust warning for pretty much every .el file. I think this would go about as well as Windows Vista UAC pop ups or State of California cancer warnings. If everything is dangerous, nothing is.
The qualifying term is 'trusted'. If you are running an application like emacs you damn sure better trust it. It's like running Windows and saying you don't trust it.
AS for macros in lisp, they are not as ubiquitous as it might seem to an outsider. I write lisp professionally. I write one macro a month, if that, and often I rewrite it as a function afterwards. Saying that macros are ubiquitous in lisp is a meme. To most lispers macros are last resort
If I understand this correctly, this exploit only works with macros that evaluate at least one of their arguments, otherwise no code is actually run. These kind of macros are not that common. I guess one possible fix would be to mark these kind of macros as potentially dangerous and do not expand them automatically for things like code completion and such.
This is what Word and Excel (used to?) do when opening (or was it previewing?) .doc and .xls files in email. Macros, if present, were disabled.
Microsoft office macros are not Lisp macros.
When you load a Lisp source code file, each of the forms and that file is read and executed.
You know like pretty much any scripting language.
You don't need a macro to perpetrate damage.
Bash doesn't have macros. yet it's a very bad idea to do this:
Lisp macros execute even when a file is not being executed but only compiled. What that means is that you have to trust a file in order to compile it because by doing so you're running it.Besides compiling any other tooling which expands macros is vulnerable to execution. As we can see in this article, there our situations when if you're working with list code inside Emacs, it will expand the macros.
If you were going to blindly run the code anyway, that makes no difference. But developers often look at untrusted source code with no intention to run it and not expecting to do anything harmful just by sitting in their editor.
In principle Lisp macros could be sandboxed. The vast majority of macros do not need to do any system access. They just look at their argument code pieces and calculate a new piece of code, without any side effects or accessing anything in the system.
As a former Emacs advocate, I only use Emacs for org-mode and magit these days.
These are still the finest stay-organized and Git UI modules I've ever seen, respectively, and are still enough to make sure I have Emacs on every system I use.
For coding, I've gone over to VS Code (and sometimes Jetbrains).
I did some FOSS hacking as a teenager a quarter-century ago, so learned Emacs, but then ultimately chose a career unrelated to software development. I still use Emacs for anything and everything text-related: email (Gnus), RSS feeds (elfeed), org-mode where I write up both personal TODOs and serious academic research. The keyboard-driven interface is powerful and now muscle-memory. The in-built Lisp environment makes everything nicely extensible, but Emacs as an IDE, as something people have used to create general software projects, is something I rarely think about.
You use VSCode for coding, and Emacs for org and magit. What do you use for everything else? :-)
As a sibling comment pointed out, many, if not most, long term heavy Emacs users are not using it for coding.
> long term heavy Emacs users are not using it for coding.
That's not true. I have worked in number of teams where Emacs users were the majority. Most of them didn't use Org, some of them never used Magit, yet they've used it for coding.
> I have worked in number of teams where Emacs users were the majority.
If most Emacs users aren't using it for programming, don't you think it's silly to narrow pick SW professionals as your population to sample from?
Hey, don't call my gang silly. They're not the ones who use Emacs for everything but coding, like some silly weirdos. :)
This sounds like you shouldn't trust untrusted code. The only real attack vector I can see is if something fucks with MELPA packages that a lot of people use I guess.
I'm obligated by tenants of my faith to point out that the best protection for this exploit is use of Vi(m) or NeoVim. You may throw tomatoes as soon as I duck behind this fence, thank you.
vim used to have similar vulnerabilities (maybe still does?) via modelines:
https://security.stackexchange.com/questions/36001/vim-model...
https://lwn.net/Articles/20249/
Circa 2002-2003, and the LWN comment describing the exact same scope:
"""emacs is the same, if not worse. (See the node File Variables in the info docs.) You get not only to set random buffer-local variables, but also to evaluate arbitrary lisp code. Ouch!"""
At least for file variables, Emacs prompts before loading untrusted values.
Someone took the first tomato!
I'm firmly in the vim camp, just wanting to share the history, utterly surprised (but not...) that it's ~25+ years in the making.
Funny story once checking a bug report, OG founder of the company dropped in: "I like to check in on my bug reports every 10 years..."
It's not just an open-source issue, hard decisions are hard decisions.
The as a fellow renter of your faith, I’m are worried that somebody playing with the “modeline” option might burn down the place.
"Tenets" of your faith. "Tenants" means that you are leasing out space in your faith to other people.
Wasn't the protestant reformation more or less about the tenants of that faith not wanting to pay rent anymore?
"tenants" clearly being the superior option
Best protection from exploits is to disconnect your computer, shut it down, smash it with a sledgehammer, quit your job and become a florist.
Whenever you folks say "just use Bla-bla instead of Emacs", you don't realize it's not even at the level of comparison between iOS and Android.
Emacs provides unique capabilities that other applications simply cannot match in terms of simplicity and power.
Like take for example Dired. Sure, there are number of vim plugins, but none of them match the full power of Emacs' Dired of treating directories as editable text.
Or take Org-mode's source blocks. You can for example execute a piece of javascript, then pipe the result into another block in python, then the results of that into sql and finally output it as a chart.
Or you can use source blocks for literate programming. I use them for managing my dotfiles - my entire system is almost immutable, not at the same level of Nix, but still very nice.
Or take an Emacs package called consult-omni - you can type a search query once and it dynamically dispatches queries to Google, YouTube, Wikipedia, your browser history and other places, aggregating the results in one place. Crazy thing is that the package builts on top of another package which itself uses the built-in functions of Emacs.
The power comes from ability to precisely change a behavior of any given function - built-in or a third party - that precision is just impossible in Vim, VSCode or IntelliJ - in Emacs, you can change specific point of any given function without having to rewrite it.
It's not a matter of "faith" as you put it. People who choose Emacs don't do that because of some dogmas, beliefs or folklore. Emacs has earned its reputation as the most extensible software for sound technical reasons. Naturally, any powerful tool can be wielded for both constructive and destructive purposes. But you can't just suggest replacing a Caterpillar 797F Mining Truck with a electric scooter because of 'security concerns' - what am I supposed to do with my 400-ton payload of customizations?
I'm obligated as part of my faith to point out that nano has none of these issues, as I understand that Vim will still execute arbitrary code in some circumstances
I believe I nothing, but even I know that ed is the standard editor.
Of course it does except vim users have no idea how to read vim code so they wouldnt even know
you're kidding but as an evil-mode user my first thought was "okay, inspect untrusted elisp in vim before opening it in emacs, got it"
Thanks for downvoting! I'm not sure why that isn't a valid approach, but then, I've never understood why people have a competition between a text editor and a Lisp machine that has an implementation of that text editor in it
And vice-versa. Brilliant!
[flagged]
Step one: use vi Step two: there is no step two.
Ed is the standard editor.
?
https://www.gnu.org/fun/jokes/ed-msg.en.html
top tier response
Emacs is not an editor. It's a Lisp REPL that has a built-in editor. It's much more than an editor.
ed advocacy and useful tips: https://x.com/ed1conf