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

[Robert Pluim <rpluim@gmail.com>]

>>>>> On Fri, 07 Jun 2024 09:42:18 +0300, Eli Zaretskii <eliz@gnu.org> said:
    >> 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?

    Eli> That ship sailed when we decided to allow manuals to be written in
    Eli> Org.  So discussing this now is way too late, unless you want to
    Eli> suggest to go back on that decision and force all the manuals to be
    Eli> written in Texinfo.

Allowing Org just added another markup language. Subverting that
requires crafting documentation that causes the texinfo or org
handling code to misbehave. I doubt thatʼs impossible, given the
ingenuity of attackers, but enabling direct evaluation of emacs lisp
makes such subversion a whole lot easier.

    >> 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).

    Eli> So you are saying that our co-maintainers are not to be trusted not to
    Eli> sneak such code into release tarballs?  That's quite an insult, I'd
    Eli> say.

Itʼs not a question of trust, nor an attack on maintainersʼ ability:
hiding such code from well-intentioned, skilled maintainers can and
has been done.

    Eli> Why is it that a crime perpetrated by some villain immediately causes
    Eli> people to suspect everyone around them to be capable of similar
    Eli> crimes?

Nobody is accusing maintainers of bad intentions. My point was merely
that we should think carefully about enabling such a feature.

If the end result is that documentation changes are inspected more
closely, thatʼs not necessarily a bad thing.

Robert
--