Re: master c86995d07e9: Enable code block evaluation when generating .org manuals

[<tomas@tuxteam.de>]

[-- Attachment #1: Type: text/plain, Size: 1773 bytes --]

On Fri, Jun 07, 2024 at 11:54:55AM +0800, Po Lu wrote:
> Robert Pluim <rpluim@gmail.com> writes:
> 
> >>>>>> On Thu,  6 Jun 2024 08:36:16 -0400 (EDT), Eli Zaretskii <eliz@gnu.org> said:
> >
> >     Eli> diff --git a/doc/misc/Makefile.in b/doc/misc/Makefile.in
> >     Eli> index 2841916dc89..b26d3525a22 100644
> >     Eli> --- a/doc/misc/Makefile.in
> >     Eli> +++ b/doc/misc/Makefile.in
> >     Eli> @@ -250,6 +250,7 @@ define org_template
> >     Eli>   $(1:.org=.texi): $(1) ${top_srcdir}/lisp/org/ox-texinfo.el
> >     Eli>  	$${AM_V_GEN}cd "$${srcdir}" && $${emacs} -l ox-texinfo \
> >     Eli>  	  --eval '(setq gc-cons-threshold 50000000)' \
> >     Eli> +	  --eval '(setq org-confirm-babel-evaluate nil)' \
> >     Eli>  	  -f org-texinfo-export-to-texinfo-batch $$(notdir $$<) $$(notdir $$@)
> >     Eli>  endef
> >
> > This has set off my paranoia alarm. So anyone that manages to
> > sneak malicious emacs lisp code into the org manual gets to run that
> > code on the machines of everyone who builds emacs from source?
> 
> No doubt you meant that anyone who manages to sneak malicious code into
> Emacs gets to run that code on the machines of everyone who builds Emacs
> from source, which is stating the obvious...

This is, strictly speaking, right, of course. Expectation-wise it does
lower the bar for an attacker somewhat, since now the malicious code just
has to be snuck into documentation.

So I think Robert is right that it's worth a discussion (whatever the
outcome might be: perhaps treat the doc as code and give it as much
scrutiny?

Anyway, the libxz episode shows that it seems to be easier to sneak
malicious code "elsewhere" (in that case it was the test suite, but
you get te idea).

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]