From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master c86995d07e9: Enable code block evaluation when generating .org manuals Date: Fri, 07 Jun 2024 14:01:39 +0300 Message-ID: <86h6e5f23w.fsf@gnu.org> References: <171767737644.19678.784876979840850798@vcs2.savannah.gnu.org> <20240606123616.DE7C9C1F9EF@vcs2.savannah.gnu.org> <87h6e6i1mg.fsf@gmail.com> <87r0d9flv4.fsf@yahoo.com> <86msnxfe45.fsf@gnu.org> <87cyoti4nv.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22842"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tomas@tuxteam.de, luangruo@yahoo.com, emacs-devel@gnu.org, kyle@kyleam.com To: Robert Pluim Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 07 13:02:32 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sFXMd-0005jR-Nr for ged-emacs-devel@m.gmane-mx.org; Fri, 07 Jun 2024 13:02:31 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sFXLu-0004jb-Ml; Fri, 07 Jun 2024 07:01:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sFXLt-0004jQ-1X for emacs-devel@gnu.org; Fri, 07 Jun 2024 07:01:45 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sFXLs-0006sI-5v; Fri, 07 Jun 2024 07:01:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=uulV+TKF0jGQ8NCZW+gzf2oEWbMJfEACgwYg4WzQSUY=; b=QmroJmLyDfIcjpm8HQHQ iYKTVt9YqBi4I2ywPyYfpw4YVR7BanZtmUimVNo5LXLKl1OJJlk9+b9Jt72ikTf294H85SYXTyFmp 3bJfiylMSyYn9VcovIlEstyS6//Hp1QKV/th2snk968QCjgcr3Q9uo+Vax1sqgqwsZpA3UlegrcFF 9XRUnygTphZEqkLWpfEh6XTSj3mT9nGI3/eW9iP3tgmLvcTv0vqEgpatEphPIM8WdX+fBgsFiq6+z v4Knt13whgSEjkPNnH7XoFPwiSBhioUfBMQV2HrHkHHj7C4/vKSsGmxN+8+xIC16wplbFVNdTSxcf HauJTc1+2hrzZQ==; In-Reply-To: <87cyoti4nv.fsf@gmail.com> (message from Robert Pluim on Fri, 07 Jun 2024 09:38:12 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:319869 Archived-At: > From: Robert Pluim > Cc: , luangruo@yahoo.com, emacs-devel@gnu.org, > kyle@kyleam.com > Date: Fri, 07 Jun 2024 09:38:12 +0200 > > >> 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. It also introduced the fact that we run Lisp to produce documentation. > 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. Adding that single setq on the command line means "direct evaluation of Emacs Lisp", whereas running Org code (in Emacs Lisp!) to produce the manuals does not? What am I missing here? > >> 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. So you are saying that we don't understand code that we review and approve for installing? > 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. That's not the only interpretation of what's been said. The reference to xz already speaks volumes about the attitude. > My point was merely > that we should think carefully about enabling such a feature. And you think I haven't when I installed the change? Why would you think that?