From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: master c86995d07e9: Enable code block evaluation when generating .org manuals Date: Sun, 09 Jun 2024 18:12:39 +0000 Message-ID: <87y17e0yug.fsf@localhost> References: <171767737644.19678.784876979840850798@vcs2.savannah.gnu.org> <20240606123616.DE7C9C1F9EF@vcs2.savannah.gnu.org> <87h6e6i1mg.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12004"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, Kyle Meyer To: Robert Pluim , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 09 20:11:55 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 1sGN1G-0002uh-U8 for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Jun 2024 20:11:54 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sGN0V-0006QT-Jv; Sun, 09 Jun 2024 14:11:07 -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 1sGN0T-0006Oa-4b for emacs-devel@gnu.org; Sun, 09 Jun 2024 14:11:05 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sGN0Q-0005eM-BZ for emacs-devel@gnu.org; Sun, 09 Jun 2024 14:11:04 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id E8FED240105 for ; Sun, 9 Jun 2024 20:10:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1717956659; bh=U20OH1H2ZS6s/Indifzg7LU+9Wos5drOqCIUBeOQXL0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=Sfwcf7+WIaAJomzAb1S0a2lzbxBvVvAwFTeM6OlghNO3PT33JTXiOEWzRQcbxGabW UBSg1IeznPl2DXoQiNfCUqQiOv/fnaJMYhgjz6MhW/8MremcsCT8Ch7lN3mXqe3CjS Vf0oR2oUctlVBQlVNL2yG+iJLquB+1Osuy5DCCNaef/5iTQb3E614LVM3sEjxsEJeR y8Zn7Q1FipgcEy470dFBw8SZfZ31g7qIJUmkvyz0qPJdzpmDdT00dVjyXSYn/yRWX5 g8fTSWhvPWIUHlOd+GIe35eeKj017eRZz5oW1xb0dIhBqQ9K95bX2M14DXtpYYavXv YA/pvgnR97ltA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Vy3026kWrz6tyJ; Sun, 9 Jun 2024 20:10:58 +0200 (CEST) In-Reply-To: <87h6e6i1mg.fsf@gmail.com> Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:319933 Archived-At: To Eli, AFAIU, emacs-30 branch will be cut next week. This discussion is what is holding us from merging the released Org 9.7 , which we would like to see in Emacs 30. Should we wait until this discussion settles before we merge? Robert Pluim writes: > 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? > > (I know, I know, we already run emacs lisp code during the build. But > it comes from .el files, generally, not documentation). Strictly speaking, pure TeX code (which can be placed directly inside TexInfo manuals) is also executed when generating documentation. At the end, TeX is a complete programming language. And there are ways to exploit it. In any case, there is a reason we want to enable generated content in the manuals. We do not do it just for fun. The installed change allows generating parts of the manual directly from the Elisp values defined in Org mode .el files. This greatly reduces maintenance burden for certain parts of the code that must be updated every single time we add a new option. IMHO, the potential increased chance of malicious code slipping through the review process is greatly outweighed by the decreased maintenance of that (and potentially other) part(s) of the Org manual. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at