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 07:00:28 +1100 [thread overview]
Message-ID: <8635bamfgy.fsf@gmail.com> (raw)
In-Reply-To: <CADwFkm=zOc6K6=eOa_WgXrnnpCRa47wKHeB+yfDM4Q0Fjzjd8A@mail.gmail.com>
Stefan Kangas <stefankangas@gmail.com> writes:
> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> The "problem" with shell links you are describing is a question of
>> setting variables and is also disabled by default.
>>
>> eww-mode, when loading Org page, could simply set
>> org-link-shell-confirm-function to its default value.
>
> Note that with the suggested feature, any link you follow risks being
> loaded in Org mode, before the user even has a chance to inspect the
> file. Which Org features, currently existing or introduced in the
> future, would EWW have to add workarounds for?
>
> It is very hard to foresee which parts of Org will be problematic and
> have to be disabled. See the security vulnerability in enriched-mode
> that prompted the release of Emacs 25.3, for example.
>
> Adding this opens a can of worms that will expose unsuspecting users to
> a whole class of new problems. And the only benefit is to save some
> users from having to type "M-x org-mode RET", or adding call to a
> suitable hook.
>
> All in all, this seems like a bad trade-off. So I don't think we should
> add such a feature.
This concern seems to be based on FUD rather than any real or identified
risk.
The risk here is no different to risks associated with opening any org
document from a foreign source e.g. in an ELPA package. Note that org
mode's default configuration wrt code execution is to ask the user for
permission to execute. If the user can run M-x org-mode on eww buffer
containing a text file which is an org file, the same risks apply and
any vulnerability would need to be addressed anyway.
This is also very different to the issues encountered with enrich text
some years back. The problem then was with elisp code embedded in text
properties. It was a bug in how enriched text processed the data.
However, I think we are probably looking at this problem from the wrong
level. It isn't really about how to get eww to render org files in
org-mode. This issue is really about being able to customize what
function is called to 'render' the data retrieved based on the
content-type header of the content.
Currently, it is fairly straight-forward to define a custom handler
based on the URL, but not based on content-type. Being able to easily
associate a function to handle downloaded content based on the
content-type would be useful. Users could then easily add whatever
functionality they wanted based on what the server told them about the
content type.
next prev parent reply other threads:[~2022-10-26 21:44 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
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 [this message]
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=8635bamfgy.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).