4 ms·

> - Implement better sandboxing and security measures for extensions. Why, pray tell, should this be of any concern at all? Sandboxing is used when the host is

by dokyun 2y ago

> - Implement better sandboxing and security measures for extensions. Why, pray tell, should this be of any concern at all? Sandboxing is used when the host is concerned about running programs that he doesn't trust. There is no reason that an Emacs package would require security measures around it, unless it were knowingly potentially malware. The only reality in which I could see this is if people were using proprietary Emacs extensions, in which case I would entirely understand it, because then people would be willingly running malware inside their editor. Perhaps this the stance VS Code users like to take towards extensions?

tmtvl 2y ago
Well, Emacs does ship with a browser (because of course it does, that kind of thing is what makes Emacs so amazing) and we all remember the XZ Utils near-backdoor, so I think that security measures would be useful for people who decide to use a less trustworthy archive like MELPA or who install extensions with package-vc.
- anthk 2y ago
  Just create another user account and test your new stuff there.
  - jrootabega 2y ago
    How does one just test for malicious code?
    - jrootabega 2y ago
      Oh, I think I see the strategy: just declare a problem trivial and then don't follow up in any way whatsoever. Genius!
- dokyun 2y ago
  The biggest security nightmare that web browsers have to deal with is that they are always continuously running random JavaScript. Emacs' browser doesn't handle JS, which is a good thing for a simple browser. Emacs doesn't share this problem in that the Elisp that you run is all chosen by you, and it's always free and never obfuscated. I don't really see how the XZ backdoor is relevant to this conversation, since these types of exploits are the fear of server operators, and generally not people who run user programs like Emacs on their desktop. A rogue Elisp function could delete all of the files in your home directory if it wanted to, but people don't really complain about that because being able to delete files is a desirable function. If you ask me, Emacs is a program where user freedom is and should be the ultimate goal. Adding security features that the user has to jump around 'for his own good' and only really serve as idiot nets are dubiously effective and only hinder this freedom. If someone wants to install a package from a source other than the official archives, then the trust is placed in him to actually look at the source code he's received. Even if you install an official package you should still look at the code, as it's quite useful to know what's going on inside it when you want to configure it or add functionality. The vast majority of packages I use are a single file and tend to not take up more than a few screens, so they are easily understandable.
jrootabega 2y ago
A lot emacs usage today consists of running programs you shouldn't trust. And the rest of it is hard because you are either reviewing other people's libraries a lot, or simply not using other people's libraries, or updating infrequently.
foobarbaz33 2y ago
> Sandboxing is used when the host is concerned about running programs that he doesn't trust. Trust? Trusting criminals doesn't stop them from committing crime. You may trust your emacs color theme author. Pretty colors from an innocent artist. You run the theme code without any sandboxing. Everything is going well. Then the author adds a keyloger, project code scrapper, and phone-home feature in his theme. You update all your emacs packages automatically without any code review. Then you start getting emails from your companies security team asking why you uploaded sensitive projects to a 3rd party. Wouldn't it make more sense to restirct color themes to color and font related tasks? Why should a color theme be allowed to scrape sensitive code from your disk and upload it to a 3rd party without your consent?
- dokyun 2y ago
  Read my other reply in this tree. > You update all your emacs packages automatically without any code review. Then you start getting emails from your companies security team asking why you uploaded sensitive projects to a 3rd party. If you do not trust the author or maintainers of a random program and refuse to review any code updates before installing it, then you are a moron. I think if there is a concern that people would upload malicious packages, then there would be a level of trust put into the repositories that accept and offer them to review submissions before accepting them. This is still imperfect, but it shifts some responsibility off of you. > Wouldn't it make more sense to restirct color themes to color and font related tasks? Why should a color theme be allowed to scrape sensitive code from your disk and upload it to a 3rd party without your consent? Why SHOULDN'T a color theme be allowed to scrape code from your disk? Maybe the color theme is sophisticated enough to want to do that, or talk to some network. Something like a seasonal color theme that responds to the local weather might have a lot of hack value; and that is precisely the point you are missing. Emacs is not about restricting what you can and can't do, because the designers of Emacs understand that restricting what the user is allowed to do ultimately hinders freedom and creativity. It is one of the very few platforms left that's still like that, and I believe it should stay that way. If people want to use an editor that's very safe and tells them what to do rather than vice versa, then they should probably consider VS Code, or something like it which DOES upload your data to a third party without your consent, because it is smarter and knows better than you what you should be doing with your computer.

by dokyun 2y ago

tmtvl 2y ago

Well, Emacs does ship with a browser (because of course it does, that kind of thing is what makes Emacs so amazing) and we all remember the XZ Utils near-backdoor, so I think that security measures would be useful for people who decide to use a less trustworthy archive like MELPA or who install extensions with package-vc.

anthk 2y ago
Just create another user account and test your new stuff there.
- jrootabega 2y ago
  How does one just test for malicious code?
  - jrootabega 2y ago
    Oh, I think I see the strategy: just declare a problem trivial and then don't follow up in any way whatsoever. Genius!
dokyun 2y ago
The biggest security nightmare that web browsers have to deal with is that they are always continuously running random JavaScript. Emacs' browser doesn't handle JS, which is a good thing for a simple browser. Emacs doesn't share this problem in that the Elisp that you run is all chosen by you, and it's always free and never obfuscated. I don't really see how the XZ backdoor is relevant to this conversation, since these types of exploits are the fear of server operators, and generally not people who run user programs like Emacs on their desktop. A rogue Elisp function could delete all of the files in your home directory if it wanted to, but people don't really complain about that because being able to delete files is a desirable function. If you ask me, Emacs is a program where user freedom is and should be the ultimate goal. Adding security features that the user has to jump around 'for his own good' and only really serve as idiot nets are dubiously effective and only hinder this freedom. If someone wants to install a package from a source other than the official archives, then the trust is placed in him to actually look at the source code he's received. Even if you install an official package you should still look at the code, as it's quite useful to know what's going on inside it when you want to configure it or add functionality. The vast majority of packages I use are a single file and tend to not take up more than a few screens, so they are easily understandable.

jrootabega 2y ago

A lot emacs usage today consists of running programs you shouldn't trust. And the rest of it is hard because you are either reviewing other people's libraries a lot, or simply not using other people's libraries, or updating infrequently.

foobarbaz33 2y ago

> Sandboxing is used when the host is concerned about running programs that he doesn't trust. Trust? Trusting criminals doesn't stop them from committing crime. You may trust your emacs color theme author. Pretty colors from an innocent artist. You run the theme code without any sandboxing. Everything is going well. Then the author adds a keyloger, project code scrapper, and phone-home feature in his theme. You update all your emacs packages automatically without any code review. Then you start getting emails from your companies security team asking why you uploaded sensitive projects to a 3rd party. Wouldn't it make more sense to restirct color themes to color and font related tasks? Why should a color theme be allowed to scrape sensitive code from your disk and upload it to a 3rd party without your consent?

dokyun 2y ago
Read my other reply in this tree. > You update all your emacs packages automatically without any code review. Then you start getting emails from your companies security team asking why you uploaded sensitive projects to a 3rd party. If you do not trust the author or maintainers of a random program and refuse to review any code updates before installing it, then you are a moron. I think if there is a concern that people would upload malicious packages, then there would be a level of trust put into the repositories that accept and offer them to review submissions before accepting them. This is still imperfect, but it shifts some responsibility off of you. > Wouldn't it make more sense to restirct color themes to color and font related tasks? Why should a color theme be allowed to scrape sensitive code from your disk and upload it to a 3rd party without your consent? Why SHOULDN'T a color theme be allowed to scrape code from your disk? Maybe the color theme is sophisticated enough to want to do that, or talk to some network. Something like a seasonal color theme that responds to the local weather might have a lot of hack value; and that is precisely the point you are missing. Emacs is not about restricting what you can and can't do, because the designers of Emacs understand that restricting what the user is allowed to do ultimately hinders freedom and creativity. It is one of the very few platforms left that's still like that, and I believe it should stay that way. If people want to use an editor that's very safe and tells them what to do rather than vice versa, then they should probably consider VS Code, or something like it which DOES upload your data to a third party without your consent, because it is smarter and knows better than you what you should be doing with your computer.