4 ms·

I think the security issues are potentially pretty significant. It's a garbage collected language with parsers that have been run a few millions times so its n

I think the security issues are potentially pretty significant. It's a garbage collected language with parsers that have been run a few millions times so its not new code but... I generally don't do much network anything except across secure lan. I personally think using Emacs for irc or chat is bananas. Emacs can be sandboxed but mostly isn't as people do so much with it and the current model is for a single main process usually. It could evolve though and I think its inevitable that it will. Fwiw I think not just Emacs but all the ditors are more at risk from supplychain attacks and build scripts from the internet. We'll see.

metroholografix 6y ago
Why is using Emacs for IRC bananas? What do you think can happen? Give me something concrete, not vague assertions. You can spend less than 5 minutes looking over the source of RCIRC (rcirc.el, written in Emacs Lisp) where it's crystal clear that you can't have remote code execution in that Emacs Lisp code.
- WhatIsDukkha 6y ago
  Five minutes might tell you there is no (eval) in the path but I don't see how thats useful.
  - metroholografix 6y ago
    It's useful in that it demonstrates a reduced attack surface. You can immediately see that there are no command injection possibilities. Additionally, there is no potential for integer overflows, memory corruption, undefined behavior, compiler optimizing your safety checks away and so on. A parser bug in Emacs Lisp will signal an error inside Emacs which will end up in either a debugger popup buffer or a message in * Messages*. So using Emacs for IRC is pretty much the same order of bananas as using a .NET or Java client. Do you think that's bananas too?
    - WhatIsDukkha 6y ago
      I wouldn't run any irc client without firejail these days... I think Emacs should change enough that thats more viable then it is today. Really you are only poking at one set of vulnerabilities anyway? Why argue for more complacency? There is plenty of that, it never needs a champion.
      - metroholografix 6y ago
        I'm not arguing against firejail, just trying to understand your threat model. Security exists on a spectrum and there are multiple trade-offs one has to think about. Do you run Python scripts that interact with the network in firejail? I've outlined areas of Emacs where exploitable vulnerabilities could lurk. But in my view, it's far from being a "bananas" situation.
        WhatIsDukkha 6y ago
        IRC has decades of vulnerabilities and unexpected behavior atop its simple protocol. Sitting on irc with 100 channels full of randos, Emacs modules that aren't irc but also process text coming through for X or Y, misconfiguration, mime link handling, irc protocol handling, sloppy bot making "hey the builtin pretty printing for python code snippet had more implications then I anticipated", "stuff" running in emacs in between network and the irc client, add that to "noone seems to talk about or care about security issues in Emacs", yeah a big pile of risk that pretty tough to just write off, for me, to that point I think it's bananas. Especially when compared to the trivial alternative of sandboxing another client that has much less surface then a fully configured single process Emacs. You are doing what you are doing and on some level we aren't too far apart in viewing the safety of a sandboxed raw emacs+some tight set of irc+a convenient plugin X and Y vs another irc client sandboxed. But I bet you aren't doing that. I really dislike the words "threat model" in security conversations like this. Neither of us has actually done any of that formal process for this, so why ask for it?
        metroholografix 6y ago

metroholografix 6y ago

Why is using Emacs for IRC bananas? What do you think can happen? Give me something concrete, not vague assertions. You can spend less than 5 minutes looking over the source of RCIRC (rcirc.el, written in Emacs Lisp) where it's crystal clear that you can't have remote code execution in that Emacs Lisp code.

WhatIsDukkha 6y ago
Five minutes might tell you there is no (eval) in the path but I don't see how thats useful.
- metroholografix 6y ago
  It's useful in that it demonstrates a reduced attack surface. You can immediately see that there are no command injection possibilities. Additionally, there is no potential for integer overflows, memory corruption, undefined behavior, compiler optimizing your safety checks away and so on. A parser bug in Emacs Lisp will signal an error inside Emacs which will end up in either a debugger popup buffer or a message in * Messages*. So using Emacs for IRC is pretty much the same order of bananas as using a .NET or Java client. Do you think that's bananas too?
  - WhatIsDukkha 6y ago
    I wouldn't run any irc client without firejail these days... I think Emacs should change enough that thats more viable then it is today. Really you are only poking at one set of vulnerabilities anyway? Why argue for more complacency? There is plenty of that, it never needs a champion.
    - metroholografix 6y ago
      I'm not arguing against firejail, just trying to understand your threat model. Security exists on a spectrum and there are multiple trade-offs one has to think about. Do you run Python scripts that interact with the network in firejail? I've outlined areas of Emacs where exploitable vulnerabilities could lurk. But in my view, it's far from being a "bananas" situation.
      - WhatIsDukkha 6y ago
        IRC has decades of vulnerabilities and unexpected behavior atop its simple protocol. Sitting on irc with 100 channels full of randos, Emacs modules that aren't irc but also process text coming through for X or Y, misconfiguration, mime link handling, irc protocol handling, sloppy bot making "hey the builtin pretty printing for python code snippet had more implications then I anticipated", "stuff" running in emacs in between network and the irc client, add that to "noone seems to talk about or care about security issues in Emacs", yeah a big pile of risk that pretty tough to just write off, for me, to that point I think it's bananas. Especially when compared to the trivial alternative of sandboxing another client that has much less surface then a fully configured single process Emacs. You are doing what you are doing and on some level we aren't too far apart in viewing the safety of a sandboxed raw emacs+some tight set of irc+a convenient plugin X and Y vs another irc client sandboxed. But I bet you aren't doing that. I really dislike the words "threat model" in security conversations like this. Neither of us has actually done any of that formal process for this, so why ask for it?
        metroholografix 6y ago