Stefan Kangas <stefankan...@gmail.com> writes:
> Ihor Radchenko <yanta...@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.
