"Dr. Arne Babenhauserheide" <arne_...@web.de> writes:
> [[PGP Signed Part:Undecided]] > > Ihor Radchenko <yanta...@posteo.net> writes: > >> If necessary, we can introduce a special variable in Org mode that will >> disable all the potential third-party code evaluation, even if user has >> customized Org to execute code without prompt. > > If that would be part of org-mode, this would be close to a > safe-org-mode. > > An important part in what I wrote about safe-org-mode is that it has to > ensure that what is shown cannot trick the user into thinking something > else would get run. > > A way to reduce risk would be to introduce a domain-allow-list (or > prefix-allow-list) in eww for filetypes that could be unsafe, so you > could for example add "orgmode.org" to your allowlist and for those > domains org-files would auto-open in org-mode. > > Such security risks have a tendency of getting weaponized down the road > when they really hurt. Like when people didn’t care about npm > dependencies and had them suddenly deleting their files. And opening in > the currently used Emacs may give a malicious file access to remote > files opened via tramp, even if you (by virtue of being careful) require > a password for the connection to sensitive servers. That way, running > something in Emacs can be even more dangerous than running it in the > shell. > and people constantly use M-x package-install to install packages from GNU ELPA, nonGNU ELPA and MELPA, often with this misguided belief that these packages are being vetted by the security fairies. As was seen after the openssl security failures, just because lots of people use something and just because lots of people may work on and look at the code, it is no guarantee the code is secure or has no malicious content. Our systems have become far too complex for such ad hoc processes providing any assurance. Likewise, as has been shown with NPM and various browser 'extension stores', packages which were once trustworthy can easily become owned/developed by new parties with less ability or are less trustworthy. While adding the sorts of controls you outline is not a bad idea, I think it is far more important to train people to accept that their system simply is not secure. You should start from the position that Emacs is not secure. Why? Because it is a large, complex and powerful piece of software which has no formal security analysis or testing and is usually augmented with numerous packages of unknown quality from largely unknown sources. Essentially, Emacs already suffers from all the same issues identified for systems like node and the NPM ecosystem. The only think which is really providing protection for us Emacs users is that the rewards for compromising Emacs are too low for the effort required. Similar to why you don't see many viruses on macOS - it isn't that it is significantly more secure than Windows (these days), but rather the pool of potential 'targets' and scale of rewards are higher when you focus on the Windows environment. It is all about return on investment. Security is a huge challenge for open source. The effort and resources required to constantly analyse and test projects for security issues is too high for most medium to large projects. The fact many open source projects also rely on other open source projects for various libraries etc also means that in addition to worrying about the security of the code in a project, the project also has to worry about 'supply chain' security i.e. ensure the external project dependencies are also secure and securely managed. So what do we do? In the famous words of Douglas Adams "Don't Panic! Rather than worry if some package or change will make Emacs less secure, assume it already is insecure and then examine how you use it and consider both the likelihood of being compromised and the impact when that occurs. This will differ depending on who you are and what you do. For example, if your a researcher working in a field where your research has high commercial value or a journalist working in countries with a poor human rights history and government parties may want to compromise your sources etc, both the likelihood and consequences could be high and you may need to take additional measures or modify how you use emacs (e.g. only use packages you have reviewed and tested and only update after formal review and testing of updated version, don't use Emacs for email or web browsing, only run emacs in an isolated locked down container etc). On the other hand, if your just a keen hobbyist, the likelihood and consequences of a security breach are both likely low and you may decide adding additional packages is an acceptable risk. Even if you decide your risks are low, you may still decide to not use Emacs for some purposes. For example, you might decide not to use Emacs for password management or not use Emacs packages which require you to keep sensitive data (toekns, passwords, API keys etc) using insecure mechanisms etc. Keep in mind that convenience and complexity are often the two biggest threats to security. Assess risks within your own personal context as what is appropriate for one person may not be for another.
