From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: bug#58774: 29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly
Date: Thu, 27 Oct 2022 08:41:13 +1100 [thread overview]
Message-ID: <86y1t2ky60.fsf@gmail.com> (raw)
In-Reply-To: <87eduusst7.fsf@web.de>
"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
> [[PGP Signed Part:Undecided]]
>
> Ihor Radchenko <yantar92@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.
next prev parent reply other threads:[~2022-10-26 22:40 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-25 12:06 29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly Jean Louis
2022-10-25 15:02 ` Dr. Arne Babenhauserheide
2022-10-25 19:56 ` Jean Louis
2022-10-25 21:54 ` Dr. Arne Babenhauserheide
2022-10-26 7:57 ` Jean Louis
2022-10-26 11:55 ` Dr. Arne Babenhauserheide
2022-10-26 12:20 ` Jean Louis
2022-10-26 12:45 ` Andreas Schwab
2022-10-26 13:19 ` bug#58774: " Jean Louis
2022-10-26 13:55 ` Andreas Schwab
2022-10-26 17:36 ` Jean Louis
2022-10-27 7:58 ` Andreas Schwab
2022-10-27 8:40 ` Jean Louis
2022-10-27 11:22 ` Andreas Schwab
2022-10-27 11:23 ` Dr. Arne Babenhauserheide
2022-10-26 7:59 ` Jean Louis
2022-10-25 23:03 ` Ihor Radchenko
2022-10-26 6:07 ` bug#58774: " Stefan Kangas
2022-10-26 6:52 ` Ihor Radchenko
2022-10-26 8:24 ` Jean Louis
2022-10-26 20:22 ` indieterminacy
2022-10-26 11:30 ` Dr. Arne Babenhauserheide
2022-10-26 21:41 ` Tim Cross [this message]
2022-10-27 10:43 ` Dr. Arne Babenhauserheide
2022-10-26 13:15 ` Stefan Kangas
2022-10-26 8:21 ` Jean Louis
2022-10-26 17:07 ` Max Nikulin
2022-10-26 18:37 ` Jean Louis
2022-10-26 21:16 ` Dr. Arne Babenhauserheide
2022-10-27 4:25 ` tomas
2022-10-27 11:10 ` Dr. Arne Babenhauserheide
2022-10-26 21:56 ` indieterminacy
2022-10-26 20:00 ` Tim Cross
2022-10-25 22:13 ` Ag Ibragimov
2022-10-26 8:28 ` Jean Louis
2022-10-26 13:00 ` Rudolf Adamkovič
2022-10-26 13:42 ` bug#58774: " Jean Louis
2022-10-27 4:55 ` Jean Louis
2022-10-27 11:13 ` Dr. Arne Babenhauserheide
2022-10-27 17:41 ` Jean Louis
2022-10-27 21:43 ` Dr. Arne Babenhauserheide
2022-10-27 15:35 ` bug#58774: " Max Nikulin
2022-10-27 17:58 ` Jean Louis
2022-10-27 21:49 ` Dr. Arne Babenhauserheide
2022-10-27 18:25 ` Jean Louis
2022-10-27 19:53 ` Quiliro Ordóñez
2022-10-27 19:58 ` Quiliro Ordóñez
2022-10-27 21:57 ` Dr. Arne Babenhauserheide
2022-10-27 22:18 ` Jean Louis
2022-10-27 23:14 ` Dr. Arne Babenhauserheide
2022-10-27 23:20 ` Ihor Radchenko
2022-10-28 8:28 ` Dr. Arne Babenhauserheide
2022-11-02 4:09 ` Ihor Radchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86y1t2ky60.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).