GNU bug report logs -
#58774
29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly
Previous Next
Reported by: Jean Louis <bugs <at> gnu.support>
Date: Tue, 25 Oct 2022 12:13:02 UTC
Severity: wishlist
Tags: wontfix
Found in version 29.0.50
Done: Stefan Kangas <stefankangas <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 58774 in the body.
You can then email your comments to 58774 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Tue, 25 Oct 2022 12:13:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jean Louis <bugs <at> gnu.support>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 25 Oct 2022 12:13:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
This wish request is related to Emacs EWW and Org mode.
Please make EWW recognize Org file when served by WWW server. Currently
it does not recognize the MIME type text/x-org and opens the file as
text, it does not invoke the org mode. In my opinion, it should.
Inspect following file by using lynx:
$ lynx -head https://gnu.support/files/tmp/example.org
uHTTP/1.1 200 OK
Server: nginx/1.14.2
Date: Tue, 25 Oct 2022 12:04:26 GMT
Content-Type: text/x-org
Content-Length: 364
Last-Modified: Tue, 25 Oct 2022 11:58:22 GMT
Connection: close
ETag: "6357cf5e-16c"
Accept-Ranges: bytes
One can see that Content-Type is text/x-org
My expectation is that EWW opens the Org file served by WWW server in
Org mode. But it doesn't. Can this be done?
This will open opportunity to directly serve Org files by using WWW
servers and to browse such files through Emacs, meaning, bunch of notes,
tasks and similar may be kept online, with or without protection and
directly accessed by Emacs. It becomes new area or WWO or World Wide Org
environment.
In GNU Emacs 29.0.50 (build 7, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.17.6, Xaw3d scroll bars) of 2022-10-10 built on
protected.rcdrun.com
Repository revision: ed436db1320339862fad5ac754a6ec42de06c766
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Parabola GNU/Linux-libre
Configured using:
'configure --with-x-toolkit=lucid'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
WEBP X11 XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB
Important settings:
value of $LC_ALL: en_US.UTF-8
value of $LANG: de_DE.UTF-8
value of $XMODIFIERS: @im=exwm-xim
locale-coding-system: utf-8-unix
Major mode: Message
Minor modes in effect:
mml-mode: t
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
line-number-mode: t
auto-fill-function: message-do-auto-fill
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
abbrev-mode: t
Load-path shadows:
None found.
Features:
(shadow sort emacsbug mail-extr org-timer org-colview org-clock
org-attach org-id org-archive org-agenda org-refile ol-eww eww xdg
url-queue thingatpt mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus
nnselect gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig
gnus-sum shr pixel-fill kinsoku url-file svg dom browse-url url
url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util url-parse auth-source cl-seq
eieio eieio-core cl-macs url-vars gnus-group gnus-undo gnus-start
gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7 nnoo
parse-time gnus-spec gnus-int gnus-range message sendmail mailcap
yank-media puny rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231
rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus
nnheader gnus-util text-property-search mail-utils range mm-util
mail-prsvr wid-edit ol-docview doc-view filenotify jka-compr image-mode
exif dired dired-loaddefs ol-bibtex ol-bbdb ol-w3m ol-doi org-link-doi
reporter org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro
org-footnote org-src ob-comint org-pcomplete pcomplete comint ansi-osc
ansi-color ring org-list org-faces org-entities noutline outline icons
org-version ob-emacs-lisp ob-core ob-eval org-table oc-basic json map
byte-opt gv bytecomp byte-compile cconv bibtex iso8601 time-date subr-x
ol rx org-keys oc org-compat advice org-macs org-loaddefs format-spec
find-func cal-menu calendar cal-loaddefs cl-loaddefs cl-lib rmc
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty make-network-process emacs)
Memory information:
((conses 16 180979 11753)
(symbols 48 19853 2)
(strings 32 68758 1519)
(string-bytes 1 2167162)
(vectors 16 37547)
(vector-slots 8 408250 18213)
(floats 8 277 76)
(intervals 56 424 0)
(buffers 1000 12))
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Tue, 25 Oct 2022 15:07:01 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Jean Louis <bugs <at> gnu.support> writes:
> This wish request is related to Emacs EWW and Org mode.
>
> Please make EWW recognize Org file when served by WWW server. Currently
> it does not recognize the MIME type text/x-org and opens the file as
> text, it does not invoke the org mode. In my opinion, it should.
This sounds dangerous. Org mode can execute untrusted code, so this
could trick people into running untrusted code with the permissions of
their Emacs.
Links in org-mode can run shell scripts. Yes, they usually ask, but this
may be changed it a local Emacs, trusting that it will only be used to
open trusted local files.
The threat model of eww changes a lot when any file on the web can
request being opened with org-mode.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Tue, 25 Oct 2022 20:05:02 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
* Dr. Arne Babenhauserheide <arne_bab <at> web.de> [2022-10-25 18:06]:
> > This wish request is related to Emacs EWW and Org mode.
> >
> > Please make EWW recognize Org file when served by WWW server. Currently
> > it does not recognize the MIME type text/x-org and opens the file as
> > text, it does not invoke the org mode. In my opinion, it should.
>
> This sounds dangerous. Org mode can execute untrusted code, so this
> could trick people into running untrusted code with the permissions of
> their Emacs.
I can always do that in Emacs, execute untrusted code. There are no
trust mechanisms for plethora of Emacs packages and codes distributed
over Internet.
That was not my request.
Do you know how to make this work?
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Tue, 25 Oct 2022 22:03:01 GMT)
Full text and
rfc822 format available.
Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Jean Louis <bugs <at> gnu.support> writes:
> * Dr. Arne Babenhauserheide <arne_bab <at> web.de> [2022-10-25 18:06]:
>> > This wish request is related to Emacs EWW and Org mode.
>> >
>> > Please make EWW recognize Org file when served by WWW server. Currently
>> > it does not recognize the MIME type text/x-org and opens the file as
>> > text, it does not invoke the org mode. In my opinion, it should.
>>
>> This sounds dangerous. Org mode can execute untrusted code, so this
>> could trick people into running untrusted code with the permissions of
>> their Emacs.
>
> I can always do that in Emacs, execute untrusted code. There are no
> trust mechanisms for plethora of Emacs packages and codes distributed
> over Internet.
All of the Emacs packages have some amount of implicit trust. Even melpa
carefully vets packages nowadays. That’s not the case for some website
you visit.
> That was not my request.
>
> Do you know how to make this work?
If you ask me whether I can make this work safely: This would first
require the introduction of a safe-org-mode which strictly disables all
features that can execute remote code or disguise unsafe operations as
safe ones. If a user then decides to explicitly call M-x org-mode,
that’s their problem.
If you ask me whether I know how to make this work unsafely: It likely
won’t need a lot of elisp reading, but I do not, because I do not look
for it, because if I did, I would not.
I do not want to be the one who caused the systems of eww users to get
breached, or who helped opening that security hole.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Tue, 25 Oct 2022 23:03:01 GMT)
Full text and
rfc822 format available.
Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):
"Dr. Arne Babenhauserheide" <arne_bab <at> web.de> writes:
> This sounds dangerous. Org mode can execute untrusted code, so this
> could trick people into running untrusted code with the permissions of
> their Emacs.
>
> Links in org-mode can run shell scripts. Yes, they usually ask, but this
> may be changed it a local Emacs, trusting that it will only be used to
> open trusted local files.
You are exaggerating the situation.
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.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 26 Oct 2022 05:08:04 GMT)
Full text and
rfc822 format available.
Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):
Can't you just use one of hooks (e.g., eww-after-render-hook) where you
inspect the URL and if it's .org, just change the mode?
This should be trivial to do, I think.
Jean Louis <bugs <at> gnu.support> writes:
> This wish request is related to Emacs EWW and Org mode.
>
> Please make EWW recognize Org file when served by WWW server. Currently
> it does not recognize the MIME type text/x-org and opens the file as
> text, it does not invoke the org mode. In my opinion, it should.
>
> Inspect following file by using lynx:
>
> $ lynx -head https://gnu.support/files/tmp/example.org
>
> uHTTP/1.1 200 OK
> Server: nginx/1.14.2
> Date: Tue, 25 Oct 2022 12:04:26 GMT
> Content-Type: text/x-org
> Content-Length: 364
> Last-Modified: Tue, 25 Oct 2022 11:58:22 GMT
> Connection: close
> ETag: "6357cf5e-16c"
> Accept-Ranges: bytes
>
> One can see that Content-Type is text/x-org
>
> My expectation is that EWW opens the Org file served by WWW server in
> Org mode. But it doesn't. Can this be done?
>
> This will open opportunity to directly serve Org files by using WWW
> servers and to browse such files through Emacs, meaning, bunch of notes,
> tasks and similar may be kept online, with or without protection and
> directly accessed by Emacs. It becomes new area or WWO or World Wide Org
> environment.
>
>
>
> In GNU Emacs 29.0.50 (build 7, x86_64-pc-linux-gnu, X toolkit, cairo
> version 1.17.6, Xaw3d scroll bars) of 2022-10-10 built on
> protected.rcdrun.com
> Repository revision: ed436db1320339862fad5ac754a6ec42de06c766
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
> System Description: Parabola GNU/Linux-libre
>
> Configured using:
> 'configure --with-x-toolkit=lucid'
>
> Configured features:
> ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
> JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY
> PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
> WEBP X11 XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB
>
> Important settings:
> value of $LC_ALL: en_US.UTF-8
> value of $LANG: de_DE.UTF-8
> value of $XMODIFIERS: @im=exwm-xim
> locale-coding-system: utf-8-unix
>
> Major mode: Message
>
> Minor modes in effect:
> mml-mode: t
> tooltip-mode: t
> global-eldoc-mode: t
> show-paren-mode: t
> electric-indent-mode: t
> mouse-wheel-mode: t
> tool-bar-mode: t
> menu-bar-mode: t
> file-name-shadow-mode: t
> global-font-lock-mode: t
> font-lock-mode: t
> blink-cursor-mode: t
> line-number-mode: t
> auto-fill-function: message-do-auto-fill
> transient-mark-mode: t
> auto-composition-mode: t
> auto-encryption-mode: t
> auto-compression-mode: t
> abbrev-mode: t
>
> Load-path shadows:
> None found.
>
> Features:
> (shadow sort emacsbug mail-extr org-timer org-colview org-clock
> org-attach org-id org-archive org-agenda org-refile ol-eww eww xdg
> url-queue thingatpt mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus
> nnselect gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig
> gnus-sum shr pixel-fill kinsoku url-file svg dom browse-url url
> url-proxy url-privacy url-expand url-methods url-history url-cookie
> generate-lisp-file url-domsuf url-util url-parse auth-source cl-seq
> eieio eieio-core cl-macs url-vars gnus-group gnus-undo gnus-start
> gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7 nnoo
> parse-time gnus-spec gnus-int gnus-range message sendmail mailcap
> yank-media puny rfc822 mml mml-sec password-cache epa derived epg
> rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231
> rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus
> nnheader gnus-util text-property-search mail-utils range mm-util
> mail-prsvr wid-edit ol-docview doc-view filenotify jka-compr image-mode
> exif dired dired-loaddefs ol-bibtex ol-bbdb ol-w3m ol-doi org-link-doi
> reporter org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro
> org-footnote org-src ob-comint org-pcomplete pcomplete comint ansi-osc
> ansi-color ring org-list org-faces org-entities noutline outline icons
> org-version ob-emacs-lisp ob-core ob-eval org-table oc-basic json map
> byte-opt gv bytecomp byte-compile cconv bibtex iso8601 time-date subr-x
> ol rx org-keys oc org-compat advice org-macs org-loaddefs format-spec
> find-func cal-menu calendar cal-loaddefs cl-loaddefs cl-lib rmc
> iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
> lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
> tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
> newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
> rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
> font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
> simple cl-generic indonesian philippine cham georgian utf-8-lang
> misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
> cp51932 hebrew greek romanian slovak czech european ethiopic indian
> cyrillic chinese composite emoji-zwj charscript charprop case-table
> epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
> loaddefs faces cus-face macroexp files window text-properties overlay
> sha1 md5 base64 format env code-pages mule custom widget keymap
> hashtable-print-readable backquote threads dbusbind inotify lcms2
> dynamic-setting system-font-setting font-render-setting cairo x-toolkit
> xinput2 x multi-tty make-network-process emacs)
>
> Memory information:
> ((conses 16 180979 11753)
> (symbols 48 19853 2)
> (strings 32 68758 1519)
> (string-bytes 1 2167162)
> (vectors 16 37547)
> (vector-slots 8 408250 18213)
> (floats 8 277 76)
> (intervals 56 424 0)
> (buffers 1000 12))
>
> --
> Jean
>
> Take action in Free Software Foundation campaigns:
> https://www.fsf.org/campaigns
>
> In support of Richard M. Stallman
> https://stallmansupport.org/
Added tag(s) wontfix.
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Wed, 26 Oct 2022 05:53:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 26 Oct 2022 06:08:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 58774 <at> debbugs.gnu.org (full text, mbox):
Ihor Radchenko <yantar92 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 26 Oct 2022 06:53:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 58774 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
> Ihor Radchenko <yantar92 <at> 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?
That's not the case. Org never loads arbitrary code on loading the file
without querying the user.
The problem raised above is what happens when user tries to open a shell
link and _also_ customized org-link-shell-confirm-function to nil (which
is explicitly marked as dangerous option).
Strictly speaking, even eww-mode may run arbitrary code given that user
puts something into eww-mode-hook.
> 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.
I'd say that it will be safer to take care about necessary precautions
rather than leaving the user with the only option to run org-mode
manually.
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.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 26 Oct 2022 08:01:02 GMT)
Full text and
rfc822 format available.
Message #31 received at submit <at> debbugs.gnu.org (full text, mbox):
* Dr. Arne Babenhauserheide <arne_bab <at> web.de> [2022-10-26 01:02]:
> All of the Emacs packages have some amount of implicit trust.
Users are unaware what package may do, and packages are everywhere on
Internet. That is not a problem that I wish to solve.
> If you ask me whether I can make this work safely: This would first
> require the introduction of a safe-org-mode which strictly disables all
> features that can execute remote code or disguise unsafe operations as
> safe ones. If a user then decides to explicitly call M-x org-mode,
> that’s their problem.
Thanks, though, that was not my request.
Please note that you miss very important issue, and that is that all
browsers support customization on how to open specific content types,
so it is quite trivial to customize in browser to open Common Lisp
program with Common Lisp.
Thus all of browsers who allow content type customization are
analogous to problem you are presenting, which in fact is no practical
problem at all.
Find the victim first, then present the problem.
To understand is that content type opening is generally not secure and
that it is user choice.
I am user of Org mode, and all I wish is to adapt eww to invoke
command "org-mode" once content type text/x-org has been recognized.
This way I can browse Org files directly, it is very useful for me as
I have bunch of files.
> If you ask me whether I know how to make this work unsafely: It likely
> won’t need a lot of elisp reading, but I do not, because I do not look
> for it, because if I did, I would not.
Well then 👀
> I do not want to be the one who caused the systems of eww users to get
> breached, or who helped opening that security hole.
See above, all other content types and URL links may be customized by
user to be opened how users want it.
Your security presentation lacks the background knowledge.
See the attached screenshot how easy it was to customize IceWeasel or
Firefox derivate to open Org files by using Emacs client. I have
script called "edit" which invoces emacsclient.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 26 Oct 2022 08:01:02 GMT)
Full text and
rfc822 format available.
Message #34 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Forgot this attached file, so you can see how easy it is to customize
Iceweasel to open Org files, it works well.
Org files are native to Emacs, I wish to open Org files by using EWW.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
[2022-10-26-10:55:26.png (image/png, attachment)]
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 26 Oct 2022 08:22:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 58774 <at> debbugs.gnu.org (full text, mbox):
* Stefan Kangas <stefankangas <at> gmail.com> [2022-10-26 09:08]:
> Ihor Radchenko <yantar92 <at> 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.
See my previous e-mail to Arne and explanation that in almost any
browser, it is user's choice on how to open various content types.
It implies, there are numerous risks involved, and users customizing
their browsers have responsibility for their computing.
Does user need group of people to dictate what is safe and what is not
safe? That is contrary to free software principles, let users decide
how they wish to open their files.
I maybe have Common Lisp on my server and wish to open it with SBLC on
my computer. That is my choice.
Let me have that choice in EWW, which is native to Emacs for Org mode,
which is native to Emacs. It is natural.
Note that I can open Org files with other browser. But I wish to
browse my Org notes directly from within Emacs , and not just invoke
external browser, which in turn invokes again `emacsclient'. That
works well already. I hope you understand it.
> Which Org features, currently existing or introduced in the
> future, would EWW have to add workarounds for?
Only to recognize content type text/x-org and invoke Org mode. And let
users decide if to invoke org mode on content type "text/x-org".
I am even now convinced that I should be able to customize how to open
various content types, but I do not get it.
I was thinking eww will recognize at least mailcap file, as in email
client I open Org files without problems.
I see in eww.el that there is function `mailcap-view-mime' but I do
not see it is used to recognize my mailcap file where I have this
line:
text/x-org; edit %s; nametemplate=%s.org;
my "edit" script invokes emacsclient
> 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.
There is no need to disable anything by default please, leave that to
user choice.
I can open ALL kinds of files from WWW servers and decide how to open
them. That was since beginning of Internet user's choice. It is not
up to browser to tell me I should not open specific content type, or
for browser to disable how I view or use the file.
- EWW is browser
- it shall recognize content-type
- it shall then invoke ANY application by users' choice for that
content-type
Maybe I wish to open text/x-org with mousepad editor, so let me do
that. Maybe I wish to invoke different Emacs instance, let me do
that. If I wish to isolate the Emacs instance I can isolate it
without problems, but that shall be my users' choice.
Sample method of isolation of browser on single computer:
(defun browse-safe-url (url &optional arg)
"Browse URL with b"
(let ((username "joedoe")) ;; different username than my own
;; Insecurity settings for personal DISPLAY only
(shell-command "xhost +")
;; Browse URL with different username
(async-start-process "sudo" "sudo" nil "su" "-c" "--" username "-c"
(format "exec iceweasel \"%s\"" url))))
> Adding this opens a can of worms that will expose unsuspecting users to
> a whole class of new problems.
It does not.
Review well customization of content types on various browsers, it
existed since beginning of WWW.
Browser is not for HTML only, there are many content types.
> And the only benefit is to sapve some users from having to type "M-x
> org-mode RET", or adding call to a suitable hook.
It is not only benefit. Every browser shall give option to users to
decide how to open any content type.
> All in all, this seems like a bad trade-off. So I don't think we should
> add such a feature.
What if I want to open Gnumeric spreadsheet with eww? You do not want
to add that feature?
Help me open Gnumeric spreadsheet by using eww and its content type by
customization, and I will not ask you to open Org by eww, because at
that point of time I will be able to customize how to open Org content
type myself.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 26 Oct 2022 08:29:02 GMT)
Full text and
rfc822 format available.
Message #40 received at submit <at> debbugs.gnu.org (full text, mbox):
* Ag Ibragimov <agzam.ibragimov <at> gmail.com> [2022-10-26 01:13]:
> Can't you just use one of hooks (e.g., eww-after-render-hook) where you
> inspect the URL and if it's .org, just change the mode?
>
> This should be trivial to do, I think.
I need to inspect content type. Not extension.
My WWW file may be of HTML content type, while ending with .org, that
is not the way: https://www.example.com/my.file.org could have
text/html content type.
Using extension on WWW is incorrect.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 26 Oct 2022 08:29:03 GMT)
Full text and
rfc822 format available.
Message #43 received at 58774 <at> debbugs.gnu.org (full text, mbox):
* Ihor Radchenko <yantar92 <at> posteo.net> [2022-10-26 09:52]:
> Strictly speaking, even eww-mode may run arbitrary code given that user
> puts something into eww-mode-hook.
eww-mode-hook is a variable defined in ‘eww.el’.
Its value is (org-eww-extend-eww-keymap)
Please help me recognize content type by using eww-mode-hook, so that
I can invoke org mode when there is "text/x-org"
It is very useful to browse my personal notes from my personal WWW
server without invoking external browser.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 26 Oct 2022 11:57:01 GMT)
Full text and
rfc822 format available.
Message #46 received at 58774 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ihor Radchenko <yantar92 <at> 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.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 26 Oct 2022 11:59:01 GMT)
Full text and
rfc822 format available.
Message #49 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Jean Louis <bugs <at> gnu.support> writes:
>> If you ask me whether I can make this work safely: This would first
>> require the introduction of a safe-org-mode which strictly disables all
>> features that can execute remote code or disguise unsafe operations as
>> safe ones. If a user then decides to explicitly call M-x org-mode,
>> that’s their problem.
>
> Thanks, though, that was not my request.
>
> Please note that you miss very important issue, and that is that all
> browsers support customization on how to open specific content types,
> so it is quite trivial to customize in browser to open Common Lisp
> program with Common Lisp.
I may have misunderstood what you want.
Do you want eww to open text/x-org files in org-mode by default, or do
you search for a way how you can modify your local eww to open
text/x-org files with org-mode?
My worries apply to the first, not to the second (there users know what
they get into).
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
[signature.asc (application/pgp-signature, inline)]
Severity set to 'wishlist' from 'normal'
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Wed, 26 Oct 2022 12:02:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 26 Oct 2022 12:40:02 GMT)
Full text and
rfc822 format available.
Message #54 received at submit <at> debbugs.gnu.org (full text, mbox):
* Dr. Arne Babenhauserheide <arne_bab <at> web.de> [2022-10-26 14:58]:
> I may have misunderstood what you want.
>
> Do you want eww to open text/x-org files in org-mode by default, or do
> you search for a way how you can modify your local eww to open
> text/x-org files with org-mode?
>
> My worries apply to the first, not to the second (there users know what
> they get into).
If there is way to extend EWW and Emacs in such way that I can tell
EWW what to do on certain content type, just as I do with other
browsers, that would solve the problem.
Then I can say, please EWW, open "text/x-org" content type with
org-mode.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 26 Oct 2022 12:46:02 GMT)
Full text and
rfc822 format available.
Message #57 received at submit <at> debbugs.gnu.org (full text, mbox):
On Okt 26 2022, Jean Louis wrote:
> If there is way to extend EWW and Emacs in such way that I can tell
> EWW what to do on certain content type, just as I do with other
> browsers, that would solve the problem.
This is what browse-url-handlers is for.
--
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 26 Oct 2022 13:07:02 GMT)
Full text and
rfc822 format available.
Message #60 received at submit <at> debbugs.gnu.org (full text, mbox):
Jean Louis <bugs <at> gnu.support> writes:
>> This should be trivial to do, I think.
+1 and I say: consider contributing to EWW!
I noticed that the EWW manual says
PDFs are viewed inline, by default, with doc-view-mode, but this can
be customized by using the mailcap (see mailcap in Emacs MIME Manual)
mechanism, in particular mailcap-mime-data.
For some reason, it made me think that EWW uses MIME correctly.
So, I evaluated
(add-to-list 'mailcap-mime-data
(list "org"
(cons 'viewer 'org-mode)
(cons 'type "text/x-org")))
but it did not work. What the hack!
To satisfy my curiosity, I decided to look at the source code.
In eww.el, the eww-render procedure parses the content-type header and
stores its value in a local let binding. After that, it dispatches to
the various "display" procedures EWW comes with, such as
((equal (car content-type) "application/pdf")
(eww-display-pdf))
The eww-display-pdf procedure then looks up the MIME viewer for the
application/pdf MIME type specifically.
If no dispatch fits, EWW ends up calling eww-display-raw.
TL;DR EWW hard-codes a couple of MIME types.
You could improve the situation in various ways.
For example, you could
(1) patch EWW to expose the eww-content-type for the user to use, or
(2) patch EWW to look up MIME for not just the PDF.
You could hack something local to you as well, but a patch would make
EWW better for all of us. So, win-win!
Rudy
--
"Programming reliably -- must be an activity of an undeniably
mathematical nature […] You see, mathematics is about thinking, and
doing mathematics is always trying to think as well as possible."
-- Edsger W. Dijkstra, 1981
Rudolf Adamkovič <salutis <at> me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 26 Oct 2022 13:16:02 GMT)
Full text and
rfc822 format available.
Message #63 received at 58774 <at> debbugs.gnu.org (full text, mbox):
Ihor Radchenko <yantar92 <at> posteo.net> writes:
>> 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?
>
> That's not the case. Org never loads arbitrary code on loading the file
> without querying the user.
We seem to be miscommunicating. In the above, I was merely referring to
whether org-mode is run when visiting some URL or not, which AFAIU is a
binary thing (it either does, or it doesn't).
You seem to be talking about security features in org-mode itself, which
is related, but not the same thing. I agree that there are various
security features in org-mode. I still don't think that we should run
org-mode just because some URL requests it.
To reiterate what I said, security problems are hard to audit and
discover. We shouldn't expose users to additional risks just to add
such a minor convenience feature. It is not a good trade-off.
> Strictly speaking, even eww-mode may run arbitrary code given that user
> puts something into eww-mode-hook.
My concern is not that the users should run their own code, but that
they will inadvertently run (potentially malicious) code provided by
others.
> I'd say that it will be safer to take care about necessary precautions
> rather than leaving the user with the only option to run org-mode
> manually.
Adding a `safe-org-mode' would be an improvement, but orthogonal to
whether or not we should automatically load org-mode when visiting any
URL that presents itself as serving an org file. I think we should not
do the latter.
> 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.
That would also be an improvement, yes. It would be even better if such
a variable supported whitelisting, so that users could mark only
specific files as safe for these purposes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 26 Oct 2022 13:21:03 GMT)
Full text and
rfc822 format available.
Message #66 received at 58774 <at> debbugs.gnu.org (full text, mbox):
* Andreas Schwab <schwab <at> suse.de> [2022-10-26 15:48]:
> On Okt 26 2022, Jean Louis wrote:
>
> > If there is way to extend EWW and Emacs in such way that I can tell
> > EWW what to do on certain content type, just as I do with other
> > browsers, that would solve the problem.
>
> This is what browse-url-handlers is for.
Content type is not an URL scheme.
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 26 Oct 2022 13:43:01 GMT)
Full text and
rfc822 format available.
Message #69 received at 58774 <at> debbugs.gnu.org (full text, mbox):
* Rudolf Adamkovič via "Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> [2022-10-26 16:10]:
> So, I evaluated
>
> (add-to-list 'mailcap-mime-data
> (list "org"
> (cons 'viewer 'org-mode)
> (cons 'type "text/x-org")))
>
> but it did not work. What the hack!
>
> To satisfy my curiosity, I decided to look at the source code.
Thank you for understanding!
> TL;DR EWW hard-codes a couple of MIME types.
>
> You could improve the situation in various ways.
>
> For example, you could
>
> (1) patch EWW to expose the eww-content-type for the user to use, or
> (2) patch EWW to look up MIME for not just the PDF.
Thank you for understanding. You have given me pointers what to do, my
personal case is closed, though I am not the one who knows how to
properly patch it, and I do not see yet that there is consensus, as
few people did not understand about user preferences and rather speak
how EWW should even take care of security issues for user instead of
giving user freedom.
I have done following to make it work personally:
(defvar eww-content-type nil)
(put 'eww-content-type 'permanent-local t)
;;; in eww-render I put:
;;; (setq eww-content-type content-type)
(defun rcd-eww-content-type ()
(cond ((string-match-p "text/x-org" (car eww-content-type)) (org-mode))
(t (eww-mode))))
It is not working best, help me if you know how. I wish normal
eww-mode when it is not org-mode.
(add-hook 'eww-after-render-hook 'rcd-eww-content-type)
And now I can browse Org files from within Emacs.
Video is here:
https://gnu.support/images/gnu-emacs/2022/10/2022-10-26/2022-10-26-16:35:20.ogv
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 26 Oct 2022 13:57:02 GMT)
Full text and
rfc822 format available.
Message #72 received at 58774 <at> debbugs.gnu.org (full text, mbox):
On Okt 26 2022, Jean Louis wrote:
> * Andreas Schwab <schwab <at> suse.de> [2022-10-26 15:48]:
>> On Okt 26 2022, Jean Louis wrote:
>>
>> > If there is way to extend EWW and Emacs in such way that I can tell
>> > EWW what to do on certain content type, just as I do with other
>> > browsers, that would solve the problem.
>>
>> This is what browse-url-handlers is for.
>
> Content type is not an URL scheme.
The predicate can do whatever it needs to determine the handler.
--
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 26 Oct 2022 17:08:02 GMT)
Full text and
rfc822 format available.
Message #75 received at 58774 <at> debbugs.gnu.org (full text, mbox):
On 26/10/2022 15:21, Jean Louis wrote:
>
> (defun browse-safe-url (url &optional arg)
----------------^^^^
> "Browse URL with b"
> (let ((username "joedoe")) ;; different username than my own
> ;; Insecurity settings for personal DISPLAY only
> (shell-command "xhost +")
> ;; Browse URL with different username
> (async-start-process "sudo" "sudo" nil "su" "-c" "--" username "-c"
> (format "exec iceweasel \"%s\"" url))))
-------------------------------------------------^^^^^^
Do not name "safe" a function having security vulnerabilities. Leaving
aside XAuth issues, it allows arbitrary command execution if URL for
some reason is not properly percent-encoded.
Do you think your reasoning related to security is still convincing?
If you were just requested mapping of Content-Type to some mode in eww,
perhaps it would pass. You demanded Org mode configured by default. Org
have enough means to execute arbitrary code with minimal efforts from
user side. E.g. value of table cell may be recalculated.
Org files originating from non-trusted sources must be carefully
evaluated before opening them in Emacs.
Sometimes Org developer and maintainers do not have enough resources to
react to security-related reports. An issue not so dangerous in the
current state becomes really weird if Org mode becomes a default handler
for files fetched from net.
You may fight for your right to freely shoot your legs but you must be
careful enough to not injury people around. Reputation of Emacs may be
significantly affected by the requested change.
I am strongly against Org mode as a default handler for files downloaded
from web sites. Eww user option, if implemented, should have prominent
warning that particular mode may not be ready for such usage and each
case should be carefully evaluated for security issues.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 26 Oct 2022 18:07:02 GMT)
Full text and
rfc822 format available.
Message #78 received at 58774 <at> debbugs.gnu.org (full text, mbox):
* Andreas Schwab <schwab <at> suse.de> [2022-10-26 16:58]:
> On Okt 26 2022, Jean Louis wrote:
>
> > * Andreas Schwab <schwab <at> suse.de> [2022-10-26 15:48]:
> >> On Okt 26 2022, Jean Louis wrote:
> >>
> >> > If there is way to extend EWW and Emacs in such way that I can tell
> >> > EWW what to do on certain content type, just as I do with other
> >> > browsers, that would solve the problem.
> >>
> >> This is what browse-url-handlers is for.
> >
> > Content type is not an URL scheme.
>
> The predicate can do whatever it needs to determine the handler.
With "predicate" do you mean URI scheme?
browse-url-handlers ⇒ (("gemini:" . elpher-go) ("gopher:"
. elpher-handler-go) ("about:" . hyperscope-about) ("hyperscope:"
. hyperscope-go) ("e2dk://" . amule-handler))
An alist with elements of the form (REGEXP-OR-PREDICATE . HANDLER).
Each REGEXP-OR-PREDICATE is matched against the URL to be opened
in turn and the first match’s HANDLER is invoked with the URL.
Then -- if URL structure would provide content type, it would work.
Otherwise it is not related to my wish. The URI scheme I wish to use
is `https:' and nothing else.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 26 Oct 2022 18:38:02 GMT)
Full text and
rfc822 format available.
Message #81 received at 58774 <at> debbugs.gnu.org (full text, mbox):
* Max Nikulin <manikulin <at> gmail.com> [2022-10-26 20:10]:
> If you were just requested mapping of Content-Type to some mode in
> eww, perhaps it would pass.
That is exactly what I need, thanks
> You demanded Org mode configured by default.
Hmm, that could be some misunderstanding. I have .mailcap file and I
know I can configure any browser to open any content type how I wish
and want.
My e-mail client Mutt is opening Org files sent by Sacha Chua in org
mode with Emacs. It is my choice as user to skip downloading such
files and inspecting them.
If Mutt supports me, and Iceweasel, to open Org files with Emacs, why
not Emacs's EWW cannot support me to open Org files with Emacs??
That is completely not logical.
That is what I need and expect from EWW, it is more general and more
useful to let user customize any content type to be opened how user
wish and want.
This is because in Org files I may have links and wish to open
Gnumeric spreadsheet.
For example, if I get text/markdown (or equivalent) it would invoke
Markdown mode, for Org mode, it would invoke Org mode.
> Org have enough means to execute arbitrary code with minimal efforts
> from user side. E.g. value of table cell may be recalculated.
Those are not issues of EWW, but of Org mode in general. Similarly,
I can open spreadsheets by using Libreoffice or Gnumeric and such
spreadsheets can execute macros, I do not know how "dangerous" it is,
but that is my choice to decide upon it.
Browser like EWW, being able to accept content types, should give to
user the option to decide if to open PDF file by integrated PDF viewer
or any external PDF viewer, or to download the file, or to open the
file by user's customized function, mode or program.
Setting up content types is freedom for users to do what they want
with files.
The security aspect is in this moment highly hypothetical as victims
are not there. And it is matter of Org mode in general.
Is there much of difference of opening Org file by using EWW or
sending link to Org file to be downloaded and THEN opened by Emacs?
User not knowledgable may execute arbitrary code anyway.
Please do not blame the communication channel and users how some Org
feature is unsafe.
That is Org security issue, and not EWW issue.
HTTP is for delivery of files.
What user does with files is user's choice.
In general any Emacs package offered for download is in general
security risk, and we freely recommend them to each others. It is
quite clear that it is not safe executing software which one does not
understand or cannot decipher.
https://www.gnu.org/software/emacs/manual/html_node/efaq/Security-risks-with-Emacs.html
Me, as user, I am totally free to configure WWW server to serve
something like "application/e-lisp" as content type, and to open that
type with `emacs --batch file.el' if I want.
"Insecurity" is thus integral part of user's choice.
As Ihor and others mentioned, then it will be maybe up to user to use
Org safe mode or similar.
That is not business of web server, HTTP or browser. Those are
delivery, retrieval and presentation tools
> Org files originating from non-trusted sources must be carefully
> evaluated before opening them in Emacs.
Same applies to ANY kind of files that may be inherently
insecure. While HTML is considered secure, Javascript less than HTML,
but still contained, there are many many content types that may be
insecure, startin with APK, proprietary sotware, EXE Windows files,
any kind of programming languages, plugins, etc. Warnings are
everywhere.
Let users decide what is trusted or non trusted source.
Programmers of free software shall give users freedom.
I have full freedom to download Emacs Lisp packages and execute them
on my computer. That is same. I just want it faster.
And I also want it executed. I find it excellent that I can instruct
web server to serve me Emacs lisp which I can then execute, great. It
may not be your common usage scenario to find any use of it. I do.
There is freedom to configure browser to open packages and install
them right away, without inspecting anything.
In proprietary software world that is exactly what billion of people
already do, they download and execute proprietary software, there is
plethora of insecurity issues there.
That is up to Org mode to solve.
It is similar to Emacs warning you about local variables. So put some
warnings in Org mode.
But do not blame browser.
Browser is download, presentation and forwarding tool.
In Firefox, Content type that otherwise is not configured in browser,
may be either saved by default or browser may ask user how to open it
by default.
It is users' decision if something is safe to open or not.
I am sure that safe Org mode will solve that issue.
Instead of speaking hypothetically of insecurities about delivering
Org mode over HTTP, let us look at numerous advantages of it, they are
analogous to WWW HTML files:
- Publish your Org notes on WWW, and use them from anywhere in the
world, from any device running Emacs; remove cache if any in EWW,
and files are gone; privacy preserved;
- Use your Org files from any mobile device running Emacs; I have too
many of them and in that case I need not synchronize it at all;
- Fetch Org style reports, templates, and workflows, modify and report
back to manager;
- Browse from Org file to Org file, create Dynamic Knowledge
Repositore that staff members, group members may access and deal
with it;
- Automatically publish Org agenda, Org files directly, without
export, to WWW servers, and access from remove places;
- HTTP offers authentication mechanisms to protect private data;
I do not have special opinion of "publishing Org files" for unknown
people, if such people are not member of the group. That would require
training them to know what is Org mode, and finally why? Emacs is poor
general browser tool.
Greatest benefit of Org files being served and properly parsed by
Emacs by using HTTP is personal and group based. It is not mainly for
public use.
But one could think of it being analogous to Gemini.
https://gemini.circumlunar.space/
Public who does not use Emacs will not be interested in such.
They may download Org files and open it from file system. Same
insecurity exists by downloading them and opening them.
> Sometimes Org developer and maintainers do not have enough resources
> to react to security-related reports. An issue not so dangerous in
> the current state becomes really weird if Org mode becomes a default
> handler for files fetched from net.
Your interpretation is improper, as you mentioned "default handler for
files fetched from net" -- and I was very specific, for text/x-org
content type that EWW get possibility to invoke org mode on such
files.
Quite logical. Emacs, Org mode and EWW, those shall work together. I
am surprised that it does not.
At least Russian Nginx WWW server supports me as user to configure it
so to serve Org files as text/x-org.
Though personally I have already found buggy solution with Emacs Lisp
modification to eww render function. I must improve it.
> You may fight for your right to freely shoot your legs but you must
> be careful enough to not injury people around. Reputation of Emacs
> may be significantly affected by the requested change.
What a dramatic exaggeration! Congrats.
> I am strongly against Org mode as a default handler for files
> downloaded from web sites. Eww user option, if implemented, should
> have prominent warning that particular mode may not be ready for
> such usage and each case should be carefully evaluated for security
> issues.
Default handler is not necessary.
It is enough if users can set up how to open different content types
by which application or by which mode. It is now more general
question, like why I cannot invoke Gnumeric on gnumeric files, or
Libreoffice on spreadsheet delivered by HTTP?
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 26 Oct 2022 21:33:02 GMT)
Full text and
rfc822 format available.
Message #84 received at 58774 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Jean Louis <bugs <at> gnu.support> writes:
> Browser like EWW, being able to accept content types, should give to
> user the option to decide if to open PDF file by integrated PDF viewer
> or any external PDF viewer, or to download the file, or to open the
> file by user's customized function, mode or program.
I’m not sure why you keep pressing for this: people agreed that enabling
users to configure that (as long as it’s not the default) is a good
idea. There’s no discussion there.
Your reply was to Max saying that this must not be the default, and that
using "safe" as part of the function name is a bad idea.
> Is there much of difference of opening Org file by using EWW or
> sending link to Org file to be downloaded and THEN opened by Emacs?
There is a difference, yes: A browser only opens inline what is deemed
safe with the session-data. PDFs are only opened with pdf.js (more
restricted compared to a pdf reader). Javascript is heavily restricted
(with good reason).
Opening org-files clicked in eww directly with org-mode is like opening
a spreadsheet with active fields inline in the browser, so a rogue
formula can steal the session of your banking login.
> That is not business of web server, HTTP or browser. Those are
> delivery, retrieval and presentation tools
Yet there is so such separation between eww and org-mode.
If you want that separation, you have to open the org-file in a second
Emacs process.
If you don’t want that separation, you have to add other precautions.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Thu, 27 Oct 2022 00:11:03 GMT)
Full text and
rfc822 format available.
Message #87 received at 58774 <at> debbugs.gnu.org (full text, mbox):
On 26-10-2022 10:24, Jean Louis wrote:
> * Ihor Radchenko <yantar92 <at> posteo.net> [2022-10-26 09:52]:
>> Strictly speaking, even eww-mode may run arbitrary code given that
>> user
>> puts something into eww-mode-hook.
>
> eww-mode-hook is a variable defined in ‘eww.el’.
>
> Its value is (org-eww-extend-eww-keymap)
>
> Please help me recognize content type by using eww-mode-hook, so that
> I can invoke org mode when there is "text/x-org"
>
> It is very useful to browse my personal notes from my personal WWW
> server without invoking external browser.
Consider hacking with regards to the Gemini protocol within Emacs, its
minimalism may provide the appropriate playground for you to do things
you expect (it already provides junctures to switch to (or at least
load) html content with another non Gemini browser.
Im killing a couple of tasks my end so I cant do this for you.
However, it may be worth you experimenting with a Gemini server which
contains orgmode files.
I expect you should be able to view orgmode files (I guess they would be
treated as non Gemtext and therefore binary). If you could toggle the
appropriate mode inside something like emacs-elpher it may work to your
needs.
--
Jonathan McHugh
indieterminacy <at> libre.brussels
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Thu, 27 Oct 2022 00:11:03 GMT)
Full text and
rfc822 format available.
Message #90 received at 58774 <at> debbugs.gnu.org (full text, mbox):
On 26-10-2022 20:37, Jean Louis wrote:
>
> I do not have special opinion of "publishing Org files" for unknown
> people, if such people are not member of the group. That would require
> training them to know what is Org mode, and finally why? Emacs is poor
> general browser tool.
>
> Greatest benefit of Org files being served and properly parsed by
> Emacs by using HTTP is personal and group based. It is not mainly for
> public use.
>
> But one could think of it being analogous to Gemini.
>
> https://gemini.circumlunar.space/
>
> Public who does not use Emacs will not be interested in such.
>
> They may download Org files and open it from file system. Same
> insecurity exists by downloading them and opening them.
>
Just typical that Id raise Gemini just as you bring it up yourself (so
many mails to sift through) :)
>> Sometimes Org developer and maintainers do not have enough resources
>> to react to security-related reports. An issue not so dangerous in
>> the current state becomes really weird if Org mode becomes a default
>> handler for files fetched from net.
>
> Your interpretation is improper, as you mentioned "default handler for
> files fetched from net" -- and I was very specific, for text/x-org
> content type that EWW get possibility to invoke org mode on such
> files.
>
> Quite logical. Emacs, Org mode and EWW, those shall work together. I
> am surprised that it does not.
>
> At least Russian Nginx WWW server supports me as user to configure it
> so to serve Org files as text/x-org.
>
> Though personally I have already found buggy solution with Emacs Lisp
> modification to eww render function. I must improve it.
>
It is worth emphasizing that Gemini is conventionally designed to serve
and receive files in isolation and that browsers are not expected to do
anything beyond recognising the simple types of lines.
As such ceteris paribus Id like to thing that it should operate to
minimise threats of vulnerabilities such as spreadsheets being used to
interact with banking services.
Besides, the size and range of Gemini browsers and clients met with the
size of these tools - combined with the acutal size of the Gemini
community (let alone their competence grade) would make it a low
priority for troublemakers to prioritise.
--
Jonathan McHugh
indieterminacy <at> libre.brussels
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Thu, 27 Oct 2022 04:58:01 GMT)
Full text and
rfc822 format available.
Message #93 received at submit <at> debbugs.gnu.org (full text, mbox):
* Jean Louis <bugs <at> gnu.support> [2022-10-25 15:14]:
>
> This wish request is related to Emacs EWW and Org mode.
>
> Please make EWW recognize Org file when served by WWW server. Currently
> it does not recognize the MIME type text/x-org and opens the file as
> text, it does not invoke the org mode. In my opinion, it should.
Now is clear that main problem here is that Org advertises somewhere
to be "text" in MIME context, while it is not, it is by default
"application" and thus unsafe, see:
Application Media Types
https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.5
and understand difference to:
Text Media Types
https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.1
Thus I suggest that Org changes its MIME type and stop falsely
claiming to be "text" in MIME context, but that content type:
"application/x-org" become adopted, as that way it will become clear
that it is unsafe opening Org as falsely claimed "plain" text.
Main reason to change MIME for Org files is that Org is opened mainly
by Emacs -- and Emacs itself has programming language built-in. It is
equivalent to opening Perl file example.pl with "perl" command.
Quote from RFC6838:
-------------------
For example, a meeting scheduler might define a standard
representation for information about proposed meeting dates. An
intelligent user agent would use this information to conduct a dialog
with the user, and might then send additional material based on that
dialog. More generally, there have been several "active" languages
developed in which programs in a suitably specialized language are
transported to a remote location and automatically run in the
recipient's environment. Such applications may be defined as subtypes
of the "application" top-level type.
Other comments: one can see from above that MIME types are useful to
execute remote programs, and there is nothing fundamentally wrong with
it. We can't just speak of safety alone when we are in general
computing environment, we must also speak of usefulness.
My initial request was not to execute Babel code in Org files or any
other code in Org files, but the basic viewing, browsing and linking
capacity of Org files, similarly to HTML.
My notes are on meta level, they export to Org for presentation
purposes. Not really for execution purposes. Though it is also useful.
All I want is to access my personal read-only Org files by using WWW
and browse from one to the other by using links.
While one may achieve similar hyperlinking features with HTML export,
exporting to HTML and making sure of details is very bloated activity
that also requires much supervision of the presentation. It generates
work and takes time. It also requires browsers, separate software to
handle Org objects innate to Emacs. Why?
Generating Org files with all relational referencing and making them
accessible from WWW straight to Emacs makes life simpler.
It implies teaching Emacs EWW how to open various content types.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Thu, 27 Oct 2022 08:00:01 GMT)
Full text and
rfc822 format available.
Message #96 received at 58774 <at> debbugs.gnu.org (full text, mbox):
On Okt 26 2022, Jean Louis wrote:
> With "predicate" do you mean URI scheme?
When I write predicate, I mean predicate.
--
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Thu, 27 Oct 2022 10:19:01 GMT)
Full text and
rfc822 format available.
Message #99 received at 58774 <at> debbugs.gnu.org (full text, mbox):
* Andreas Schwab <schwab <at> suse.de> [2022-10-27 11:03]:
> On Okt 26 2022, Jean Louis wrote:
>
> > With "predicate" do you mean URI scheme?
>
> When I write predicate, I mean predicate.
Can that predicate understand content type?
Do you have an example?
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Thu, 27 Oct 2022 11:23:01 GMT)
Full text and
rfc822 format available.
Message #102 received at 58774 <at> debbugs.gnu.org (full text, mbox):
On Okt 27 2022, Jean Louis wrote:
> Can that predicate understand content type?
It can use whatever it needs to determine the handler.
--
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Thu, 27 Oct 2022 11:24:01 GMT)
Full text and
rfc822 format available.
Message #105 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Jean Louis <bugs <at> gnu.support> writes:
> * Jean Louis <bugs <at> gnu.support> [2022-10-25 15:14]:
>>
>> This wish request is related to Emacs EWW and Org mode.
>>
>> Please make EWW recognize Org file when served by WWW server. Currently
>> it does not recognize the MIME type text/x-org and opens the file as
>> text, it does not invoke the org mode. In my opinion, it should.
>
> Now is clear that main problem here is that Org advertises somewhere
> to be "text" in MIME context, while it is not, it is by default
> "application" and thus unsafe, see:
>
> Application Media Types
> https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.5
>
> and understand difference to:
>
> Text Media Types
> https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.1
>
> Thus I suggest that Org changes its MIME type and stop falsely
> claiming to be "text" in MIME context, but that content type:
> "application/x-org" become adopted, as that way it will become clear
> that it is unsafe opening Org as falsely claimed "plain" text.
You are mixing up text/plain and text/*. Orgmode is clearly text/* but
not text/plain. From your link:
Beyond plain text, there are many formats for representing what might
be known as "rich text". An interesting characteristic of many such
representations is that they are to some extent readable even without
the software that interprets them. It is useful to distinguish them,
at the highest level, from such unreadable data as images, audio, or
text represented in an unreadable form. In the absence of
appropriate interpretation software, it is reasonable to present
subtypes of "text" to the user, while it is not reasonable to do so
with most non-textual data. Such formatted textual data can be
represented using subtypes of "text".
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Thu, 27 Oct 2022 11:25:02 GMT)
Full text and
rfc822 format available.
Message #108 received at 58774 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Jean Louis <bugs <at> gnu.support> writes:
> * Andreas Schwab <schwab <at> suse.de> [2022-10-27 11:03]:
>> On Okt 26 2022, Jean Louis wrote:
>>
>> > With "predicate" do you mean URI scheme?
>>
>> When I write predicate, I mean predicate.
>
> Can that predicate understand content type?
A predicate is a function that returns true or false.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Thu, 27 Oct 2022 15:37:02 GMT)
Full text and
rfc822 format available.
Message #111 received at 58774 <at> debbugs.gnu.org (full text, mbox):
On 27/10/2022 11:55, Jean Louis wrote:
>
> Now is clear that main problem here is that Org advertises somewhere
> to be "text" in MIME context, while it is not, it is by default
> "application" and thus unsafe, see:
...
> Text Media Types
> https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.1
I do not see any problem or any difference what MIME type you are going
to associate with Org mode. I agree with Arne that text/... type is more
appropriate for a format readable as text. I do not see any
contradictions with that RFC.
"Org Mode
Your life in plain text"
Chromium is able to display text/x-org internally just as text/plain and
I like it as a way to preview and review file contents. I have not
managed to configure Firefox to achieve the same behavior that allows to
avoid an external application (certainly not Emacs at first).
> We can't just speak of safety alone when we are in general
> computing environment, we must also speak of usefulness.
I do not mind to have org-view-mode that saves me from execution some
code unintentionally. Since most of the code was written without having
in mind such feature, I expect a lot of iterations before all
possibilities to run code will be plumbed. I suspect that it is possible
to ruin whole protection by a small piece of elisp code. I am unaware of
sandboxing in Emacs. I expect that making Org mode safe enough will
require a lot of efforts by developers.
Your are pushing Org to rather hostile environment: highly automated
attacks to distribute exploits, market of breached computers listening
for remote commands. A running cryptominer would be rather innocent
consequence, through the same backdoor you may receive an encryptor or
various stuff searching for credentials and access tokens in your files.
Emacs is protected mostly by its low popularity. A lot of efforts have
been invested in browser making attacks more expensive, but still
attractive due to possible benefits. I do not like to increase surface
for attacks. Someone may create a plugin targeting Emacs users just
because it would be easy enough.
Consider converting Org files to HTML as an unpleasant tax for the sake
of safety.
> All I want is to access my personal read-only Org files by using WWW
> and browse from one to the other by using links.
How are you going to distinguish your personal files and arbitrary files
from non-trusted sources? By signing your files and maintaining list of
trusted certificates?
For personal notes I would expect e.g. private instance of nextcloud
file share (that is internally HTTP server), not accessing files
directly through HTTP.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Thu, 27 Oct 2022 19:19:01 GMT)
Full text and
rfc822 format available.
Message #114 received at 58774 <at> debbugs.gnu.org (full text, mbox):
* Max Nikulin <manikulin <at> gmail.com> [2022-10-27 18:40]:
> On 27/10/2022 11:55, Jean Louis wrote:
> >
> > Now is clear that main problem here is that Org advertises somewhere
> > to be "text" in MIME context, while it is not, it is by default
> > "application" and thus unsafe, see:
> ...
> > Text Media Types
> > https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.1
>
> I do not see any problem or any difference what MIME type you are going to
> associate with Org mode. I agree with Arne that text/... type is more
> appropriate for a format readable as text. I do not see any contradictions
> with that RFC.
You were the one speaking and reporting that Org executes Emacs Lisp.
And now you imply that it is safe to open it because it is text? 👀
If Org or any file implies possible execution when loaded, and Org
implies it, it is not any more "text/*" MIME type.
From:
https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.5
> 4.2.5. Application Media Types
> The "application" top-level type is to be used for discrete data that
> do not fit under any of the other type names, and particularly for
> data to be processed by some type of application program. This is
> information that must be processed by an application before it is
> viewable or usable by a user.
That is exactly the case with Org. Of course, one could minimize org
file to empty string, and say this is Org file and there is no
execution necessary, so it is "text".
Otherwise information must be processed by application which is
clearly the Org package before it is viewable or usable by a user.
> Expected uses for the "application" type name include but are not
> limited to file transfer, spreadsheets, presentations, scheduling
> data, and languages for "active" (computational) material.
✔️ YES, we have spreadsheets in Org which results may be viewable only
after computed.
✔️ YES, we have scheduling data, which is viewable only in Org agenda
or by using computations.
✔️ YES, we have languages for active computational material.
> (The last, in particular, can pose security problems that must be
> understood by implementors. The "application/postscript" media type
> registration in [RFC2046] provides a good example of how to handle
> these issues.)
> For example, a meeting scheduler might define a standard
> representation for information about proposed meeting dates.
✔️ YES, we have that functionality in Org.
> An intelligent user agent would use this information to conduct a
> dialog with the user, and might then send additional material based
> on that dialog.
> More generally, there have been several "active" languages developed
> in which programs in a suitably specialized language are transported
> to a remote location and automatically run in the recipient's
> environment. Such applications may be defined as subtypes of the
> "application" top-level type.
✔️ YES, that is exactly what we have in Org mode, as Babel allows
executions of several active languages, and by transferring Org files,
to remote location they may be automatically run in the recipient's
environment.
> The subtype of "application" will often either be the name or include
> part of the name of the application for which the data are intended.
> This does not mean, however, that any application program name may
> simply be used freely as a subtype of "application"; the subtype needs
> to be registered.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Thu, 27 Oct 2022 19:20:02 GMT)
Full text and
rfc822 format available.
Message #117 received at submit <at> debbugs.gnu.org (full text, mbox):
* Dr. Arne Babenhauserheide <arne_bab <at> web.de> [2022-10-27 14:23]:
>
> Jean Louis <bugs <at> gnu.support> writes:
>
> > * Jean Louis <bugs <at> gnu.support> [2022-10-25 15:14]:
> >>
> >> This wish request is related to Emacs EWW and Org mode.
> >>
> >> Please make EWW recognize Org file when served by WWW server. Currently
> >> it does not recognize the MIME type text/x-org and opens the file as
> >> text, it does not invoke the org mode. In my opinion, it should.
> >
> > Now is clear that main problem here is that Org advertises somewhere
> > to be "text" in MIME context, while it is not, it is by default
> > "application" and thus unsafe, see:
> >
> > Application Media Types
> > https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.5
> >
> > and understand difference to:
> >
> > Text Media Types
> > https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.1
> >
> > Thus I suggest that Org changes its MIME type and stop falsely
> > claiming to be "text" in MIME context, but that content type:
> > "application/x-org" become adopted, as that way it will become clear
> > that it is unsafe opening Org as falsely claimed "plain" text.
>
> You are mixing up text/plain and text/*. Orgmode is clearly text/* but
> not text/plain. From your link:
How do I mix it?
> Beyond plain text, there are many formats for representing what might
> be known as "rich text". An interesting characteristic of many such
> representations is that they are to some extent readable even without
> the software that interprets them. It is useful to distinguish them,
> at the highest level, from such unreadable data as images, audio, or
> text represented in an unreadable form. In the absence of
> appropriate interpretation software, it is reasonable to present
> subtypes of "text" to the user, while it is not reasonable to do so
> with most non-textual data. Such formatted textual data can be
> represented using subtypes of "text".
Org is not just rich text for reason as explained here:
https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.5 so I
suggest reading it.
Examples of content types for some "rich" text formats:
.odt OpenDocument text document
application/vnd.oasis.opendocument.text
.rtf Rich Text Format (RTF) application/rtf
.xhtml XHTML application/xhtml+xml
xml XML application/xml is recommended as of RFC 7303 (section
4.1), but text/xml is still used sometimes. You can assign a specific
MIME type to a file with .xml extension depending on how its contents
are meant to be interpreted. For instance, an Atom feed is
application/atom+xml, but application/xml serves as a valid default.
Review definition of "application/*" type.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Thu, 27 Oct 2022 19:20:02 GMT)
Full text and
rfc822 format available.
Message #120 received at 58774 <at> debbugs.gnu.org (full text, mbox):
* Max Nikulin <manikulin <at> gmail.com> [2022-10-27 18:41]:
> Chromium is able to display text/x-org internally just as text/plain and I
> like it as a way to preview and review file contents.
Org file is for Emacs. It is not for Chromium.
Just as you can display application/json in Chromium as text, does not
make application/json less "application/*" MIME type.
Displaying Org in Chromium is useless, as I cannot use Org features,
Chromium is not for that, and it's not suitable example.
Suitable example is that Chromium may be configured to open Org file
correctly with Emacs and as you have mentioned, there will be executions.
> I have not managed to configure Firefox to achieve the same behavior
> that allows to avoid an external application (certainly not Emacs at
> first).
I wonder on which mailing list I am.
Of course I want Org file be opened by Emacs. I am user of Org
files and Emacs. I am not vim user (unless Emacs flunks).
> > We can't just speak of safety alone when we are in general
> > computing environment, we must also speak of usefulness.
>
> I do not mind to have org-view-mode that saves me from execution some code
> unintentionally. Since most of the code was written without having in mind
> such feature, I expect a lot of iterations before all possibilities to run
> code will be plumbed. I suspect that it is possible to ruin whole protection
> by a small piece of elisp code. I am unaware of sandboxing in Emacs. I
> expect that making Org mode safe enough will require a lot of efforts by
> developers.
Exactly.
> Your are pushing Org to rather hostile environment: highly automated
> attacks to distribute exploits, market of breached computers
> listening for remote commands.
Tittle-tattle. 😵💫 But America has been already discovered.
Remember, any type of application, software, is already for billions
of times delivered by Internet and executed on user's devices.
Flatpak, APK, EXE files, Java, shell files, hoooooo, too long
list. And where we are now? In Emacs world, where packages are
distributed from all kinds of sources and executed on users's
computers.
"Pushing Org" to rather hostile environment is exaggeration.
> A running cryptominer would be rather innocent consequence, through
> the same backdoor you may receive an encryptor or various stuff
> searching for credentials and access tokens in your files.
Of course I understand that.
Do you wish to say that users should not have the freedom to customize
web browser to click on Org file and open it with Emacs?
Are we not on Emacs related mailing list?
If I am pushing Org into hostile environment, than you are implying
that we as Org users are hostile environemnt. Are we really?
> Emacs is protected mostly by its low popularity. A lot of efforts
> have been invested in browser making attacks more expensive, but
> still attractive due to possible benefits. I do not like to increase
> surface for attacks. Someone may create a plugin targeting Emacs
> users just because it would be easy enough.
And?
> Consider converting Org files to HTML as an unpleasant tax for the
> sake of safety.
Personally, definitely not. Such files do not give me freedom to work
with my Org data. It is way of presenting things, not handling it.
> > All I want is to access my personal read-only Org files by using WWW
> > and browse from one to the other by using links.
>
> How are you going to distinguish your personal files and arbitrary files
> from non-trusted sources? By signing your files and maintaining list of
> trusted certificates?
🤣 Am I Joe Biden or other gaga that I do not know what are my files?
> For personal notes I would expect e.g. private instance of nextcloud
> file share (that is internally HTTP server), not accessing files
> directly through HTTP.
HTTP is transfer protocol, not my mamma to tell me what I am going to
transfer in my room.
Nextcloud is application that runs on computer and is served by web
server. It allows file share to public as well.
I understand your point of protecting private files on web
server. That shall be natural to every person hosting such
files. Nextcloud is bloated way to do such hosting.
Simplest way to protect files is to upload files and use web server
authentication.
And web server does not mean that files are distributed on public
WWW. We use here ethernet, and we share files from device to device by
using HTTP server. You can't access those files, they are beyond
public IP address space.
I need help to make it work right, can you help?
I load this:
(defvar eww-content-type nil)
(put 'eww-content-type 'permanent-local t)
then I put this below in `eww-render' after (let
;;; (setq eww-content-type content-type)
Then I use this:
(defun rcd-eww-content-type ()
(cond ((string-match-p "text/x-org" (car eww-content-type)) (org-mode))
(t WHAT-HERE?)))
(add-hook 'eww-after-render-hook 'rcd-eww-content-type)
But I am doing it wrong, that will correctly invoke org mode, but then
it does not return back to normal EWW work. I have tried to remember
the major mode and invoke it again. But it is not that it works.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Thu, 27 Oct 2022 19:54:02 GMT)
Full text and
rfc822 format available.
Message #123 received at 58774 <at> debbugs.gnu.org (full text, mbox):
El 2022-10-27 13:25, Jean Louis escribió:
> But I am doing it wrong, that will correctly invoke org mode, but then
> it does not return back to normal EWW work. I have tried to remember
> the major mode and invoke it again. But it is not that it works.
Isn't that what hooks do? Perhaps I did not understand them correctly.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Thu, 27 Oct 2022 19:59:02 GMT)
Full text and
rfc822 format available.
Message #126 received at 58774 <at> debbugs.gnu.org (full text, mbox):
I think that this would be very useful for me. In fact, it would be a
good way to make Emac work without being a tool for corporations (as
Firefox is) to control user's computers (unless the user decides to
allow running Babel by default). Maybe even Gemini is a good candidate
to work this out.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Thu, 27 Oct 2022 21:49:02 GMT)
Full text and
rfc822 format available.
Message #129 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Jean Louis <bugs <at> gnu.support> writes:
> * Dr. Arne Babenhauserheide <arne_bab <at> web.de> [2022-10-27 14:23]:
>>
>> Jean Louis <bugs <at> gnu.support> writes:
>>
>> > * Jean Louis <bugs <at> gnu.support> [2022-10-25 15:14]:
>> >>
>> >> This wish request is related to Emacs EWW and Org mode.
>> >>
>> >> Please make EWW recognize Org file when served by WWW server. Currently
>> >> it does not recognize the MIME type text/x-org and opens the file as
>> >> text, it does not invoke the org mode. In my opinion, it should.
>> >
>> > Now is clear that main problem here is that Org advertises somewhere
>> > to be "text" in MIME context, while it is not, it is by default
>> > "application" and thus unsafe, see:
>> >
>> > Application Media Types
>> > https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.5
>> >
>> > and understand difference to:
>> >
>> > Text Media Types
>> > https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.1
>> >
>> > Thus I suggest that Org changes its MIME type and stop falsely
>> > claiming to be "text" in MIME context, but that content type:
>> > "application/x-org" become adopted, as that way it will become clear
>> > that it is unsafe opening Org as falsely claimed "plain" text.
>>
>> You are mixing up text/plain and text/*. Orgmode is clearly text/* but
>> not text/plain. From your link:
>
> How do I mix it?
The paragraph about plain text only applies to text/plain.
The following paragraph shows clearly that org-mode is rich-text,
because it can be read without specialized program. And it is: I
sometimes read org-mode documents with nano.
>> Beyond plain text, there are many formats for representing what might
>> be known as "rich text". An interesting characteristic of many such
>> representations is that they are to some extent readable even without
>> the software that interprets them. It is useful to distinguish them,
>> at the highest level, from such unreadable data as images, audio, or
>> text represented in an unreadable form. In the absence of
>> appropriate interpretation software, it is reasonable to present
>> subtypes of "text" to the user, while it is not reasonable to do so
>> with most non-textual data. Such formatted textual data can be
>> represented using subtypes of "text".
>
> Org is not just rich text for reason as explained here:
> https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.5 so I
> suggest reading it.
This is information that must be processed by an application before it is
viewable or usable by a user"
That is very much *not* the case for org-mode documents.
You’ll have to quote a specific point you mean, because I do not find
anything that supports your point in there.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Thu, 27 Oct 2022 21:58:02 GMT)
Full text and
rfc822 format available.
Message #132 received at 58774 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Jean Louis <bugs <at> gnu.support> writes:
> * Max Nikulin <manikulin <at> gmail.com> [2022-10-27 18:40]:
>> On 27/10/2022 11:55, Jean Louis wrote:
>> >
>> > Now is clear that main problem here is that Org advertises somewhere
>> > to be "text" in MIME context, while it is not, it is by default
>> > "application" and thus unsafe, see:
>> ...
>> > Text Media Types
>> > https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.1
>>
>> I do not see any problem or any difference what MIME type you are going to
>> associate with Org mode. I agree with Arne that text/... type is more
>> appropriate for a format readable as text. I do not see any contradictions
>> with that RFC.
>
> You were the one speaking and reporting that Org executes Emacs Lisp.
>
> And now you imply that it is safe to open it because it is text? 👀
>
> If Org or any file implies possible execution when loaded, and Org
> implies it, it is not any more "text/*" MIME type.
Whether or not something *can* be executed is irrelevant for text/* vs.
application/*. Relevant is whether something *must* be executed for the
document to be usable.
> From:
> https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.5
>
>> 4.2.5. Application Media Types
>
>> The "application" top-level type is to be used for discrete data that
>> do not fit under any of the other type names, and particularly for
>> data to be processed by some type of application program. This is
>> information that must be processed by an application before it is
>> viewable or usable by a user.
>
> That is exactly the case with Org. Of course, one could minimize org
> file to empty string, and say this is Org file and there is no
> execution necessary, so it is "text".
>
> Otherwise information must be processed by application which is
> clearly the Org package before it is viewable or usable by a user.
#+title: I disagree
* Firstoff
because this is a valid org-structure.
* Second
because you can use this.
#+begin_src bash
echo "even the embedded source here"
#+end_src
* Test
If you could not read the two arguments
_without_ first processing this section with org-mode
then I am wrong. If so, please tell me /"could not read"/.
That said: If you tell me /"could not read"/ I know
that you *could* read this section, so you would be wrong.
* Conclusion
Org mode documents belong into text/*
>> Expected uses for the "application" type name include but are not
>> limited to file transfer, spreadsheets, presentations, scheduling
>> data, and languages for "active" (computational) material.
>
> ✔️ YES, we have spreadsheets in Org which results may be viewable only
> after computed.
application/* and text/* are not distinguished by their domain, but by
whether they are readable as plain text.
Same for your other points.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Thu, 27 Oct 2022 22:09:01 GMT)
Full text and
rfc822 format available.
Message #135 received at 58774 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Max Nikulin <manikulin <at> gmail.com> writes:
> How are you going to distinguish your personal files and arbitrary
> files from non-trusted sources? By signing your files and maintaining
> list of trusted certificates?
One idea that could work well is to add an explicit allow-list
trusted-sources-to-allow-unsafe-modes with entries of domain and
path-prefix where people can add trusted sources.
If for example my server were draketo.de,¹ I could set this list to
'(("https://www.draketo.de" "/software"))
and when I would then open a link like
https://www.draketo.de/software/advent-of-wisp-code-2021.org
with eww, it would directly switch to org-mode.
If, however, I would open the link
https://draketo.de.evil.attacks/software/advent-of-wisp-code-2021.org
with eww, it would display it as plain text, because it would not be in
the list of trusted sources.
Best wishes,
Arne
¹: hypothetically speaking :-)
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Thu, 27 Oct 2022 22:20:01 GMT)
Full text and
rfc822 format available.
Message #138 received at 58774 <at> debbugs.gnu.org (full text, mbox):
* Dr. Arne Babenhauserheide <arne_bab <at> web.de> [2022-10-28 01:11]:
>
> Max Nikulin <manikulin <at> gmail.com> writes:
>
> > How are you going to distinguish your personal files and arbitrary
> > files from non-trusted sources? By signing your files and maintaining
> > list of trusted certificates?
>
> One idea that could work well is to add an explicit allow-list
> trusted-sources-to-allow-unsafe-modes with entries of domain and
> path-prefix where people can add trusted sources.
That implies that for every content type you are supposed to do the
same.
And what makes you want to limit people how they want to run their Org
files?
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Thu, 27 Oct 2022 23:20:02 GMT)
Full text and
rfc822 format available.
Message #141 received at 58774 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Jean Louis <bugs <at> gnu.support> writes:
> * Dr. Arne Babenhauserheide <arne_bab <at> web.de> [2022-10-28 01:11]:
>>
>> Max Nikulin <manikulin <at> gmail.com> writes:
>>
>> > How are you going to distinguish your personal files and arbitrary
>> > files from non-trusted sources? By signing your files and maintaining
>> > list of trusted certificates?
>>
>> One idea that could work well is to add an explicit allow-list
>> trusted-sources-to-allow-unsafe-modes with entries of domain and
>> path-prefix where people can add trusted sources.
>
> That implies that for every content type you are supposed to do the
> same.
No, you misunderstood the proposal.
> And what makes you want to limit people how they want to run their Org
> files?
The wish to limit the fallout when¹ this gets weaponized by criminals.
If you explicitly allow-list trusted sources, bad actors have to take
over your trusted server to attack you. That’s much less likely than bad
actors taking over some random long-unmainted server of a link you
stumbled upon.
¹: when, not if.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Thu, 27 Oct 2022 23:20:02 GMT)
Full text and
rfc822 format available.
Message #144 received at 58774 <at> debbugs.gnu.org (full text, mbox):
"Dr. Arne Babenhauserheide" <arne_bab <at> web.de> writes:
> Max Nikulin <manikulin <at> gmail.com> writes:
>
>> How are you going to distinguish your personal files and arbitrary
>> files from non-trusted sources? By signing your files and maintaining
>> list of trusted certificates?
>
> One idea that could work well is to add an explicit allow-list
> trusted-sources-to-allow-unsafe-modes with entries of domain and
> path-prefix where people can add trusted sources.
>
> If for example my server were draketo.de,¹ I could set this list to
>
> '(("https://www.draketo.de" "/software"))
>
> and when I would then open a link like
>
> https://www.draketo.de/software/advent-of-wisp-code-2021.org
>
> with eww, it would directly switch to org-mode.
>
>
> If, however, I would open the link
>
> https://draketo.de.evil.attacks/software/advent-of-wisp-code-2021.org
>
> with eww, it would display it as plain text, because it would not be in
> the list of trusted sources.
I am a bit lost about the aim of this tread, but let me share some
existing remote resource controls we have employed on the latest Org:
(defun org--should-fetch-remote-resource-p (uri)
"Return non-nil if the URI should be fetched."
(defun org--safe-remote-resource-p (uri)
"Return non-nil if URI is considered safe.
This checks every pattern in `org-safe-remote-resources', and
returns non-nil if any of them match."
(defun org--confirm-resource-safe (uri)
"Ask the user if URI should be considered safe, returning non-nil if so."
You can check the implementation at
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/org.el#n4540
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Fri, 28 Oct 2022 08:38:02 GMT)
Full text and
rfc822 format available.
Message #147 received at 58774 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ihor Radchenko <yantar92 <at> posteo.net> writes:
> "Dr. Arne Babenhauserheide" <arne_bab <at> web.de> writes:
>
>> One idea that could work well is to add an explicit allow-list
>> trusted-sources-to-allow-unsafe-modes with entries of domain and
>> path-prefix where people can add trusted sources.
>>
>> If for example my server were draketo.de,¹ I could set this list to
>>
>> '(("https://www.draketo.de" "/software"))
>>
>> and when I would then open a link like
>>
>> https://www.draketo.de/software/advent-of-wisp-code-2021.org
>>
>> with eww, it would directly switch to org-mode.
>
> I am a bit lost about the aim of this tread, but let me share some
> existing remote resource controls we have employed on the latest Org:
> (defun org--safe-remote-resource-p (uri)
> "Return non-nil if URI is considered safe.
> This checks every pattern in `org-safe-remote-resources', and
> returns non-nil if any of them match."
> You can check the implementation at
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/org.el#n4540
That’s pretty awesome! Thank you!
So we could have companywide shared setupfiles without granting
ssh-access to machines …
… and to the topic: this may be something that could be re-used in eww.
Though I would prefer having a less-intrusive notification than a y-n
question; maybe just a message in the echo area that with a specific
command this uri could be marked as safe and then get interpreted as org
right away.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58774; Package
emacs.
(Wed, 02 Nov 2022 04:10:02 GMT)
Full text and
rfc822 format available.
Message #150 received at 58774 <at> debbugs.gnu.org (full text, mbox):
"Dr. Arne Babenhauserheide" <arne_bab <at> web.de> writes:
> … and to the topic: this may be something that could be re-used in
> eww.
Yup. Or Emacs could even provide a unified interface to ask security
questions.
> Though I would prefer having a less-intrusive notification than a y-n
> question; maybe just a message in the echo area that with a specific
> command this uri could be marked as safe and then get interpreted as org
> right away.
We have modelled the dialogue after what Emacs does for file-local
variables. This kind of security questions should be very clearly
visible and, ideally, unified to make sure that users can easily
distinguish important queries.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Reply sent
to
Stefan Kangas <stefankangas <at> gmail.com>:
You have taken responsibility.
(Sat, 02 Sep 2023 08:54:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Jean Louis <bugs <at> gnu.support>:
bug acknowledged by developer.
(Sat, 02 Sep 2023 08:54:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 58774-done <at> debbugs.gnu.org (full text, mbox):
Jean Louis <bugs <at> gnu.support> writes:
> This wish request is related to Emacs EWW and Org mode.
>
> Please make EWW recognize Org file when served by WWW server. Currently
> it does not recognize the MIME type text/x-org and opens the file as
> text, it does not invoke the org mode. In my opinion, it should.
>
> Inspect following file by using lynx:
>
> $ lynx -head https://gnu.support/files/tmp/example.org
>
> uHTTP/1.1 200 OK
> Server: nginx/1.14.2
> Date: Tue, 25 Oct 2022 12:04:26 GMT
> Content-Type: text/x-org
> Content-Length: 364
> Last-Modified: Tue, 25 Oct 2022 11:58:22 GMT
> Connection: close
> ETag: "6357cf5e-16c"
> Accept-Ranges: bytes
>
> One can see that Content-Type is text/x-org
>
> My expectation is that EWW opens the Org file served by WWW server in
> Org mode. But it doesn't. Can this be done?
>
> This will open opportunity to directly serve Org files by using WWW
> servers and to browse such files through Emacs, meaning, bunch of notes,
> tasks and similar may be kept online, with or without protection and
> directly accessed by Emacs. It becomes new area or WWO or World Wide Org
> environment.
The discussion here showed that this will introduce security issues and
is not something we want to do.
I'm therefore closing this feature request as wontfix.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 30 Sep 2023 11:24:27 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 224 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.