X-Loop: help-debbugs@HIDDEN Subject: bug#77341: [PATCH] ; (find-function-search-for-symbol): Be cautious with macros. Resent-From: Eshel Yaron <me@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Fri, 28 Mar 2025 17:29:02 +0000 Resent-Message-ID: <handler.77341.B.174318290422662 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: report 77341 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: 77341 <at> debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@HIDDEN Received: via spool by submit <at> debbugs.gnu.org id=B.174318290422662 (code B ref -1); Fri, 28 Mar 2025 17:29:02 +0000 Received: (at submit) by debbugs.gnu.org; 28 Mar 2025 17:28:24 +0000 Received: from localhost ([127.0.0.1]:55410 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tyDVH-0005tR-Js for submit <at> debbugs.gnu.org; Fri, 28 Mar 2025 13:28:23 -0400 Received: from lists.gnu.org ([2001:470:142::17]:56122) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <me@HIDDEN>) id 1tyDVF-0005t7-I5 for submit <at> debbugs.gnu.org; Fri, 28 Mar 2025 13:28:22 -0400 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 <me@HIDDEN>) id 1tyDV5-00031k-W1 for bug-gnu-emacs@HIDDEN; Fri, 28 Mar 2025 13:28:12 -0400 Received: from mail.eshelyaron.com ([107.175.124.16] helo=eshelyaron.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <me@HIDDEN>) id 1tyDV4-00008Q-Ap for bug-gnu-emacs@HIDDEN; Fri, 28 Mar 2025 13:28:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1743182889; bh=UWt7XdM35MgWia3FUHrjRVjIeeZqd4vLUYBVSJuiArQ=; h=From:To:Subject:Date:From; b=LGpDLpg2gX7TIUW2awhrLou2/rZbjCdSIQlf4arc/6Tt6KktHRRro2SOdNwm/9kkE AXOmOHYulbooFHAr3zg21I8hyomncYnqR+Ut2VzFgRxO6zD9r0s8VtUTcSuoGH+Qx+ Ljya6R3sBcrywwDkU+y1ftghPVR2l6xNeSQozpdjx+CbO7BUkSmh18BvFH+xq+Y8vU IteXcyYn69+B/ZE/XSCL6AzHvgNIr311rPuSxoC4itcFbkqx0izj3H4tP1qwK9JmfF ZkRwmW7NTB4+hB6L1K4KjpxIvIqxdcUW/Gxzy5sICRcjJdqkkmm/jdhsz5wd3tMdXZ dZlCiLIbEybxA== From: Eshel Yaron <me@HIDDEN> Date: Fri, 28 Mar 2025 18:28:06 +0100 Message-ID: <m1bjtl6p5l.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=107.175.124.16; envelope-from=me@HIDDEN; helo=eshelyaron.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.1 (/) --=-=-= Content-Type: text/plain Tags: patch Hi, find-function may expand Lisp macros in a source file when it fails to find a definition otherwise. This patch restricts this fallback to trusted buffers only, to protect against possibly harmful macros. Eshel --=-=-= Content-Type: text/patch Content-Disposition: attachment; filename=0001-find-function-search-for-symbol-Be-cautious-with-mac.patch From a29b2c0888a19069aef8ef248979c4b463e26f5c Mon Sep 17 00:00:00 2001 From: Eshel Yaron <me@HIDDEN> Date: Fri, 28 Mar 2025 17:57:35 +0100 Subject: [PATCH] ; (find-function-search-for-symbol): Be cautious with macros. * lisp/emacs-lisp/find-func.el (find-function-search-for-symbol): Only attempt to expand macros in trusted buffers. --- lisp/emacs-lisp/find-func.el | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/lisp/emacs-lisp/find-func.el b/lisp/emacs-lisp/find-func.el index 8f488a9c00a..6bdfb4bc38b 100644 --- a/lisp/emacs-lisp/find-func.el +++ b/lisp/emacs-lisp/find-func.el @@ -487,11 +487,14 @@ find-function-search-for-symbol ;; If the regexp search didn't find the location of ;; the symbol (for example, because it is generated by ;; a macro), try a slightly more expensive search that - ;; expands macros until it finds the symbol. + ;; expands macros until it finds the symbol. Since + ;; macro-expansion involves arbitrary code execution, + ;; only attempt it in trusted buffers. (cons (current-buffer) - (find-function--search-by-expanding-macros - (current-buffer) symbol type - form-matcher-factory)))))))))) + (when (trusted-content-p) + (find-function--search-by-expanding-macros + (current-buffer) symbol type + form-matcher-factory))))))))))) ;;;###autoload (defun find-function-update-type-alist (symbol type variable) -- 2.48.1 --=-=-=--
Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) Content-Type: text/plain; charset=utf-8 X-Loop: help-debbugs@HIDDEN From: help-debbugs@HIDDEN (GNU bug Tracking System) To: Eshel Yaron <me@HIDDEN> Subject: bug#77341: Acknowledgement ([PATCH] ; (find-function-search-for-symbol): Be cautious with macros.) Message-ID: <handler.77341.B.174318290422662.ack <at> debbugs.gnu.org> References: <m1bjtl6p5l.fsf@HIDDEN> X-Gnu-PR-Message: ack 77341 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: patch Reply-To: 77341 <at> debbugs.gnu.org Date: Fri, 28 Mar 2025 17:29:02 +0000 Thank you for filing a new bug report with debbugs.gnu.org. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): bug-gnu-emacs@HIDDEN If you wish to submit further information on this problem, please send it to 77341 <at> debbugs.gnu.org. Please do not send mail to help-debbugs@HIDDEN unless you wish to report a problem with the Bug-tracking system. --=20 77341: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D77341 GNU Bug Tracking System Contact help-debbugs@HIDDEN with problems
X-Loop: help-debbugs@HIDDEN Subject: bug#77341: [PATCH] ; (find-function-search-for-symbol): Be cautious with macros. Resent-From: Daniel Colascione <dancol@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Fri, 28 Mar 2025 19:44:02 +0000 Resent-Message-ID: <handler.77341.B.174319103314111 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 77341 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: me@HIDDEN, 77341 <at> debbugs.gnu.org X-Debbugs-Original-To: Eshel Yaron <me@HIDDEN>, "Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>, 77341 <at> debbugs.gnu.org Received: via spool by submit <at> debbugs.gnu.org id=B.174319103314111 (code B ref -1); Fri, 28 Mar 2025 19:44:02 +0000 Received: (at submit) by debbugs.gnu.org; 28 Mar 2025 19:43:53 +0000 Received: from localhost ([127.0.0.1]:55566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tyFcP-0003fX-6W for submit <at> debbugs.gnu.org; Fri, 28 Mar 2025 15:43:53 -0400 Received: from lists.gnu.org ([2001:470:142::17]:53682) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1tyFcN-0003f8-Q3 for submit <at> debbugs.gnu.org; Fri, 28 Mar 2025 15:43:52 -0400 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 <dancol@HIDDEN>) id 1tyFcI-0007YA-3q for bug-gnu-emacs@HIDDEN; Fri, 28 Mar 2025 15:43:46 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <dancol@HIDDEN>) id 1tyFcF-000573-Vv for bug-gnu-emacs@HIDDEN; Fri, 28 Mar 2025 15:43:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: References:In-Reply-To:Subject:To:From:Date:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=zxV3goknyMiJoJS5691VmFtzhc3o2wU+pp7sJI3Hc0k=; b=EXUNGe3JquZ4sd0vS/evWORUJx OALa46GGkDHAij193MZCIkSVKbhnp1G+kMFMzIuhtkhg2A6MK2UI1MAmT74Q1GyzlDfy8+jpzdEhP X/Y/HYCyaw30rMRUCJ6QmmzsOGPR9X3HPzEklak+Q0Ig/Reh9gGpv99BjL1k/ZWw2lmKMFJlwL3eT zlv4iWLidIFE/yJa6JRoGSsTXtayMtbi7SQdEnQiyJuHt0fbRJxikjx54o2pqCIc+6mX2Faao5XHK y+uge5zphmIKwHZPCJE6Ny/YCU6WxIOIs8rx2b05H5eDnLfmIAqB3657Slp3oeXrdo+mqBIbaVDZS 2EIQ7Vdg==; Received: from [2600:1006:b114:5ef0:0:7:d2d3:2501] (port=49654 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from <dancol@HIDDEN>) id 1tyFbn-004Ljg-36; Fri, 28 Mar 2025 15:43:16 -0400 Date: Fri, 28 Mar 2025 15:43:35 -0400 From: Daniel Colascione <dancol@HIDDEN> User-Agent: K-9 Mail for Android In-Reply-To: <m1bjtl6p5l.fsf@HIDDEN> References: <m1bjtl6p5l.fsf@HIDDEN> Message-ID: <4CA9F756-3DE4-461F-BABC-2FC0E629755D@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2600:3c01:e000:3d8::1; envelope-from=dancol@HIDDEN; helo=dancol.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.1 (/) On March 28, 2025 1:28:06 PM EDT, "Eshel Yaron via Bug reports for GNU Ema= cs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu=2Eorg> wrote: >Tags: patch > >Hi, > >find-function may expand Lisp macros in a source file when it fails to >find a definition otherwise=2E This patch restricts this fallback to >trusted buffers only, to protect against possibly harmful macros=2E I get not wanting to execute code from random files I'm just visiting, but= if I've already actually evaluated a macro function and installed it in my= Emacs function namespace as something I can call, is it all that dangerous= to call it? Instead of a blanket prohibition on macro expansion, I'd rathe= r have macros declare that they're safe to run on untrusted inputs, which m= eans mostly they don't eval their arguments=2E
X-Loop: help-debbugs@HIDDEN Subject: bug#77341: [PATCH] ; (find-function-search-for-symbol): Be cautious with macros. Resent-From: Daniel Colascione <dancol@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Fri, 28 Mar 2025 19:44:02 +0000 Resent-Message-ID: <handler.77341.B77341.174319102714090 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 77341 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: me@HIDDEN, 77341 <at> debbugs.gnu.org X-Debbugs-Original-To: Eshel Yaron <me@HIDDEN>, "Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>, 77341 <at> debbugs.gnu.org Received: via spool by 77341-submit <at> debbugs.gnu.org id=B77341.174319102714090 (code B ref 77341); Fri, 28 Mar 2025 19:44:02 +0000 Received: (at 77341) by debbugs.gnu.org; 28 Mar 2025 19:43:47 +0000 Received: from localhost ([127.0.0.1]:55563 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tyFcI-0003fB-Ln for submit <at> debbugs.gnu.org; Fri, 28 Mar 2025 15:43:47 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:44516) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1tyFcF-0003ew-KX for 77341 <at> debbugs.gnu.org; Fri, 28 Mar 2025 15:43:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: References:In-Reply-To:Subject:To:From:Date:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=zxV3goknyMiJoJS5691VmFtzhc3o2wU+pp7sJI3Hc0k=; b=EXUNGe3JquZ4sd0vS/evWORUJx OALa46GGkDHAij193MZCIkSVKbhnp1G+kMFMzIuhtkhg2A6MK2UI1MAmT74Q1GyzlDfy8+jpzdEhP X/Y/HYCyaw30rMRUCJ6QmmzsOGPR9X3HPzEklak+Q0Ig/Reh9gGpv99BjL1k/ZWw2lmKMFJlwL3eT zlv4iWLidIFE/yJa6JRoGSsTXtayMtbi7SQdEnQiyJuHt0fbRJxikjx54o2pqCIc+6mX2Faao5XHK y+uge5zphmIKwHZPCJE6Ny/YCU6WxIOIs8rx2b05H5eDnLfmIAqB3657Slp3oeXrdo+mqBIbaVDZS 2EIQ7Vdg==; Received: from [2600:1006:b114:5ef0:0:7:d2d3:2501] (port=49654 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from <dancol@HIDDEN>) id 1tyFbn-004Ljg-36; Fri, 28 Mar 2025 15:43:16 -0400 Date: Fri, 28 Mar 2025 15:43:35 -0400 From: Daniel Colascione <dancol@HIDDEN> User-Agent: K-9 Mail for Android In-Reply-To: <m1bjtl6p5l.fsf@HIDDEN> References: <m1bjtl6p5l.fsf@HIDDEN> Message-ID: <4CA9F756-3DE4-461F-BABC-2FC0E629755D@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On March 28, 2025 1:28:06 PM EDT, "Eshel Yaron via Bug reports for GNU Ema= cs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu=2Eorg> wrote: >Tags: patch > >Hi, > >find-function may expand Lisp macros in a source file when it fails to >find a definition otherwise=2E This patch restricts this fallback to >trusted buffers only, to protect against possibly harmful macros=2E I get not wanting to execute code from random files I'm just visiting, but= if I've already actually evaluated a macro function and installed it in my= Emacs function namespace as something I can call, is it all that dangerous= to call it? Instead of a blanket prohibition on macro expansion, I'd rathe= r have macros declare that they're safe to run on untrusted inputs, which m= eans mostly they don't eval their arguments=2E
X-Loop: help-debbugs@HIDDEN Subject: bug#77341: [PATCH] ; (find-function-search-for-symbol): Be cautious with macros. Resent-From: Eshel Yaron <me@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Sat, 29 Mar 2025 06:55:02 +0000 Resent-Message-ID: <handler.77341.B.174323128118648 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 77341 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Daniel Colascione <dancol@HIDDEN> Cc: 77341 <at> debbugs.gnu.org X-Debbugs-Original-Cc: "Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>, 77341 <at> debbugs.gnu.org Received: via spool by submit <at> debbugs.gnu.org id=B.174323128118648 (code B ref -1); Sat, 29 Mar 2025 06:55:02 +0000 Received: (at submit) by debbugs.gnu.org; 29 Mar 2025 06:54:41 +0000 Received: from localhost ([127.0.0.1]:56487 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tyQ5Y-0004qh-HT for submit <at> debbugs.gnu.org; Sat, 29 Mar 2025 02:54:40 -0400 Received: from lists.gnu.org ([2001:470:142::17]:33968) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <me@HIDDEN>) id 1tyQ5W-0004qF-8M for submit <at> debbugs.gnu.org; Sat, 29 Mar 2025 02:54:38 -0400 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 <me@HIDDEN>) id 1tyQ5Q-0003b9-ES for bug-gnu-emacs@HIDDEN; Sat, 29 Mar 2025 02:54:32 -0400 Received: from mail.eshelyaron.com ([107.175.124.16] helo=eshelyaron.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <me@HIDDEN>) id 1tyQ5O-0005Qf-3s for bug-gnu-emacs@HIDDEN; Sat, 29 Mar 2025 02:54:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1743231269; bh=feWpBfGuijCQdeJ/RdnbSrF/KUqiYBfXifOBL0hwkH8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=F4SToiLzKStVdtSjnR3Ek5NVllBxeAvVFIo9mUDsLrk9ER8OEmkT1S10y58eE20AE Pegpo0kBbz6OT9zLCnJBE+ibs5zbcF7M/h0zfGkbO8VWgkq1cVCWjXz5Ym90TG+sne H2kE++54rO2o3omRFxfhBQBCvvlAK5dQUZrZYxsAQt6Pi3Ja2gUtEGjUQwdMJD1nUS 0to8MD3eMmB8Wqi2QElfLd5ftmoGmkjYJz4KsLQIMYFRwEv3y+yr+GxrPgiDztzO+V 0rk13TFHmULR+tcSR3yZ72lL7met/ViEyb2zR7mrxhTzbGgo5IFbCbvP9EBIsXnCnO YxPtfg9s3q69w== From: Eshel Yaron <me@HIDDEN> In-Reply-To: <4CA9F756-3DE4-461F-BABC-2FC0E629755D@HIDDEN> References: <m1bjtl6p5l.fsf@HIDDEN> <4CA9F756-3DE4-461F-BABC-2FC0E629755D@HIDDEN> Date: Sat, 29 Mar 2025 07:54:26 +0100 Message-ID: <m1h63cconx.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=107.175.124.16; envelope-from=me@HIDDEN; helo=eshelyaron.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.1 (/) Daniel Colascione <dancol@HIDDEN> writes: > On March 28, 2025 1:28:06 PM EDT, Eshel Yaron wrote: >>Tags: patch >> >>find-function may expand Lisp macros in a source file when it fails to >>find a definition otherwise. This patch restricts this fallback to >>trusted buffers only, to protect against possibly harmful macros. > > I get not wanting to execute code from random files I'm just visiting, > but if I've already actually evaluated a macro function and installed > it in my Emacs function namespace as something I can call, is it all > that dangerous to call it? find-function searches through code you haven't evaluated/loaded too. Even for loaded libraries, the source file/buffer contents may be different than the loaded code. Either way, if you trust some files, you can add them to trusted-content. If you haven't, that means they are untrusted. In general, as long as macro-expansion remains unsafe, we should avoid expanding untrusted macros in commands that merely edit/browse Lisp code (in contrast with compiling/evaluating it). > Instead of a blanket prohibition on macro expansion, (To be clear, I wouldn't say there's a prohibition on macro expansion, just a restriction to trusted code, similarly to proper code evaluation, since they're not that different in practice.) > I'd rather have macros declare that they're safe to run on untrusted > inputs, which means mostly they don't eval their arguments. Yes, please :) Even better, we should have a safe evaluation sandbox that can be used for safe macro-expansion among other things. Indeed, any solution that allows us to safely expand (most) macros would be a great improvement. But until we have something like that, we should guard macro-expansion behind trusted-content-p checks. Regards, Eshel
X-Loop: help-debbugs@HIDDEN Subject: bug#77341: [PATCH] ; (find-function-search-for-symbol): Be cautious with macros. Resent-From: Eshel Yaron <me@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Sat, 29 Mar 2025 06:55:02 +0000 Resent-Message-ID: <handler.77341.B77341.174323127418620 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 77341 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Daniel Colascione <dancol@HIDDEN> Cc: 77341 <at> debbugs.gnu.org X-Debbugs-Original-Cc: "Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>, 77341 <at> debbugs.gnu.org Received: via spool by 77341-submit <at> debbugs.gnu.org id=B77341.174323127418620 (code B ref 77341); Sat, 29 Mar 2025 06:55:02 +0000 Received: (at 77341) by debbugs.gnu.org; 29 Mar 2025 06:54:34 +0000 Received: from localhost ([127.0.0.1]:56484 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tyQ5R-0004qG-NP for submit <at> debbugs.gnu.org; Sat, 29 Mar 2025 02:54:34 -0400 Received: from mail.eshelyaron.com ([107.175.124.16]:33666 helo=eshelyaron.com) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <me@HIDDEN>) id 1tyQ5N-0004q6-Mr for 77341 <at> debbugs.gnu.org; Sat, 29 Mar 2025 02:54:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1743231269; bh=feWpBfGuijCQdeJ/RdnbSrF/KUqiYBfXifOBL0hwkH8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=F4SToiLzKStVdtSjnR3Ek5NVllBxeAvVFIo9mUDsLrk9ER8OEmkT1S10y58eE20AE Pegpo0kBbz6OT9zLCnJBE+ibs5zbcF7M/h0zfGkbO8VWgkq1cVCWjXz5Ym90TG+sne H2kE++54rO2o3omRFxfhBQBCvvlAK5dQUZrZYxsAQt6Pi3Ja2gUtEGjUQwdMJD1nUS 0to8MD3eMmB8Wqi2QElfLd5ftmoGmkjYJz4KsLQIMYFRwEv3y+yr+GxrPgiDztzO+V 0rk13TFHmULR+tcSR3yZ72lL7met/ViEyb2zR7mrxhTzbGgo5IFbCbvP9EBIsXnCnO YxPtfg9s3q69w== From: Eshel Yaron <me@HIDDEN> In-Reply-To: <4CA9F756-3DE4-461F-BABC-2FC0E629755D@HIDDEN> References: <m1bjtl6p5l.fsf@HIDDEN> <4CA9F756-3DE4-461F-BABC-2FC0E629755D@HIDDEN> Date: Sat, 29 Mar 2025 07:54:26 +0100 Message-ID: <m1h63cconx.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Daniel Colascione <dancol@HIDDEN> writes: > On March 28, 2025 1:28:06 PM EDT, Eshel Yaron wrote: >>Tags: patch >> >>find-function may expand Lisp macros in a source file when it fails to >>find a definition otherwise. This patch restricts this fallback to >>trusted buffers only, to protect against possibly harmful macros. > > I get not wanting to execute code from random files I'm just visiting, > but if I've already actually evaluated a macro function and installed > it in my Emacs function namespace as something I can call, is it all > that dangerous to call it? find-function searches through code you haven't evaluated/loaded too. Even for loaded libraries, the source file/buffer contents may be different than the loaded code. Either way, if you trust some files, you can add them to trusted-content. If you haven't, that means they are untrusted. In general, as long as macro-expansion remains unsafe, we should avoid expanding untrusted macros in commands that merely edit/browse Lisp code (in contrast with compiling/evaluating it). > Instead of a blanket prohibition on macro expansion, (To be clear, I wouldn't say there's a prohibition on macro expansion, just a restriction to trusted code, similarly to proper code evaluation, since they're not that different in practice.) > I'd rather have macros declare that they're safe to run on untrusted > inputs, which means mostly they don't eval their arguments. Yes, please :) Even better, we should have a safe evaluation sandbox that can be used for safe macro-expansion among other things. Indeed, any solution that allows us to safely expand (most) macros would be a great improvement. But until we have something like that, we should guard macro-expansion behind trusted-content-p checks. Regards, Eshel
X-Loop: help-debbugs@HIDDEN Subject: bug#77341: [PATCH] ; (find-function-search-for-symbol): Be cautious with macros. Resent-From: Daniel Colascione <dancol@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Sat, 29 Mar 2025 15:00:02 +0000 Resent-Message-ID: <handler.77341.B77341.174326039823788 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 77341 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eshel Yaron <me@HIDDEN> Cc: 77341 <at> debbugs.gnu.org X-Debbugs-Original-Cc: "Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>, 77341 <at> debbugs.gnu.org Received: via spool by 77341-submit <at> debbugs.gnu.org id=B77341.174326039823788 (code B ref 77341); Sat, 29 Mar 2025 15:00:02 +0000 Received: (at 77341) by debbugs.gnu.org; 29 Mar 2025 14:59:58 +0000 Received: from localhost ([127.0.0.1]:60744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tyXfB-0006Ba-IU for submit <at> debbugs.gnu.org; Sat, 29 Mar 2025 10:59:58 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:48294) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1tyXf8-0006BP-Aa for 77341 <at> debbugs.gnu.org; Sat, 29 Mar 2025 10:59:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: References:In-Reply-To:Subject:CC:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=n3eFHyP+Kl9LHo/hbSzQcFhRG+1HrEFGZRondAvq3pU=; b=WSy4N8cNQ9XQD/IAk1Bm7uojbY RiKNgurgPiM+0nP0aNv/CKWXU38s6kUZyto52bNpKlSEGLUnGWyUQdnGcKY1ICmsuK0+a/WTRQqTT qbEjjZahSRTDKMJTM0p4VwfxmvauwCufLXIdggMfAAGtbxMI1MfiFNthSsIvP+PRqmqZwawtXVoBe qmZY00UVP7HYFUNlRnO0BxcEDZ7xnQS1jsCHeqOH7gGMRBZOy61ueqBpbOSn0EqPQTcTZZ2pCfX3x 9toaooooQV04HXe8vrR6s1KMGfchLs+ZDHieBTQpD/WEBCQqJm63GOCDpe+mDy2CEWYYHXYk1HJST BjMGyxUA==; Received: from 2603-9001-4203-1ab2-ef66-22ee-8864-07c9.inf6.spectrum.com ([2603:9001:4203:1ab2:ef66:22ee:8864:7c9]:46928 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from <dancol@HIDDEN>) id 1tyXeg-004QAb-1J; Sat, 29 Mar 2025 10:59:26 -0400 Date: Sat, 29 Mar 2025 10:59:49 -0400 From: Daniel Colascione <dancol@HIDDEN> User-Agent: K-9 Mail for Android In-Reply-To: <m1h63cconx.fsf@HIDDEN> References: <m1bjtl6p5l.fsf@HIDDEN> <4CA9F756-3DE4-461F-BABC-2FC0E629755D@HIDDEN> <m1h63cconx.fsf@HIDDEN> Message-ID: <2286A4A5-8E75-4D95-939C-7BEE3B2C580F@HIDDEN> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=----EMCF8KR1KFEKRJWKYNZXRNI8RKV9CO Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) ------EMCF8KR1KFEKRJWKYNZXRNI8RKV9CO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On March 29, 2025 2:54:26 AM EDT, Eshel Yaron <me@eshelyaron=2Ecom> wrote: >Daniel Colascione <dancol@dancol=2Eorg> writes: > >> On March 28, 2025 1:28:06 PM EDT, Eshel Yaron wrote: >>>Tags: patch >>> >>>find-function may expand Lisp macros in a source file when it fails to >>>find a definition otherwise=2E This patch restricts this fallback to >>>trusted buffers only, to protect against possibly harmful macros=2E >> >> I get not wanting to execute code from random files I'm just visiting, >> but if I've already actually evaluated a macro function and installed >> it in my Emacs function namespace as something I can call, is it all >> that dangerous to call it?=20 > >find-function searches through code you haven't evaluated/loaded too=2E >Even for loaded libraries, the source file/buffer contents may be >different than the loaded code=2E Either way, if you trust some files, >you can add them to trusted-content=2E If you haven't, that means they >are untrusted=2E > >In general, as long as macro-expansion remains unsafe, we should avoid >expanding untrusted macros in commands that merely edit/browse Lisp code >(in contrast with compiling/evaluating it)=2E > >> Instead of a blanket prohibition on macro expansion, > >(To be clear, I wouldn't say there's a prohibition on macro expansion, >just a restriction to trusted code, similarly to proper code evaluation, >since they're not that different in practice=2E) > >> I'd rather have macros declare that they're safe to run on untrusted >> inputs, which means mostly they don't eval their arguments=2E > >Yes, please :) Macros are just transformers from lists to lists=2E If a macro doesn't exe= cute its input data, you can pass radioactive waste through it just fine=2E= If we can trust a macro to handle untrusted data safely, we don't need to = trust its inputs=2E It should work like this: 1) presumptively, expansion of a trusted form is safe no matter which macr= o is doing the expanding=20 2) by default, expansion of untrusted forms is unsafe=20 3) however, #2 can be overridden if a macro declares (probably via oclosur= e slot) "I am safely process untrusted input" Now we can expand most macros in practice even in untrusted code because m= ost of the time the macros will be coming from the Emacs core, the macros o= f which we'll annotate as safe=2E No reason whatsoever that we shouldn't be= able to expand, say, a cl-defgeneric form in an untrusted file=2E (We should use an oclosure instead of a plist property so we can easily at= tach the attribute to macrolet macros too) Probably simplest to make the safety annotation just another declare form= =2E I'd love to integrate it into edebug specs, but sadly edebug doesn't ha= ve an API other components can use to extract and use the information embed= ded in debug specs, and current edebug syntax doesn't have all the informat= ion we'd need for safety=2E (Oh, this macro takes a sexp? I can still eval = it during expansion!) >Even better, we should have a safe evaluation sandbox that can be used >for safe macro-expansion among other things=2E Indeed, any solution that >allows us to safely expand (most) macros would be a great improvement=2E >But until we have something like that, we should guard macro-expansion >behind trusted-content-p checks=2E I think we need a little more nuance than that ------EMCF8KR1KFEKRJWKYNZXRNI8RKV9CO Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE html><html><body><div dir=3D"auto"><br><br>On March 29, 2025 2:54= :26 AM EDT, Eshel Yaron <me@eshelyaron=2Ecom> wrote:<br>>Daniel Co= lascione <dancol@dancol=2Eorg> writes:<br>><br>>> On March 2= 8, 2025 1:28:06 PM EDT, Eshel Yaron wrote:<br>>>>Tags: patch<br>&g= t;>><br>>>>find-function may expand Lisp macros in a source = file when it fails to<br>>>>find a definition otherwise=2E=C2=A0 T= his patch restricts this fallback to<br>>>>trusted buffers only, t= o protect against possibly harmful macros=2E<br>>><br>>> I get = not wanting to execute code from random files I'm just visiting,<br>>>= ; but if I've already actually evaluated a macro function and installed<br>= >> it in my Emacs function namespace as something I can call, is it a= ll<br>>> that dangerous to call it? <br>><br>>find-function sea= rches through code you haven't evaluated/loaded too=2E<br>>Even for load= ed libraries, the source file/buffer contents may be<br>>different than = the loaded code=2E=C2=A0 Either way, if you trust some files,<br>>you ca= n add them to trusted-content=2E=C2=A0 If you haven't, that means they<br>&= gt;are untrusted=2E<br>><br>>In general, as long as macro-expansion r= emains unsafe, we should avoid<br>>expanding untrusted macros in command= s that merely edit/browse Lisp code<br>>(in contrast with compiling/eval= uating it)=2E<br>><br>>> Instead of a blanket prohibition on macro= expansion,<br>><br>>(To be clear, I wouldn't say there's a prohibiti= on on macro expansion,<br>>just a restriction to trusted code, similarly= to proper code evaluation,<br>>since they're not that different in prac= tice=2E)<br>><br>>> I'd rather have macros declare that they're sa= fe to run on untrusted<br>>> inputs, which means mostly they don't ev= al their arguments=2E<br>><br>>Yes, please :)<br><br><br>Macros are j= ust transformers from lists to lists=2E If a macro doesn't execute its inpu= t data, you can pass radioactive waste through it just fine=2E If we can tr= ust a macro to handle untrusted data safely, we don't need to trust its inp= uts=2E<br><br>It should work like this:<br><br>1) presumptively, expansion = of a trusted form is safe no matter which macro is doing the expanding <br>= <br>2) by default, expansion of untrusted forms is unsafe <br><br>3) howeve= r, #2 can be overridden if a macro declares (probably via oclosure slot) "I= am safely process untrusted input"<br><br>Now we can expand most macros in= practice even in untrusted code because most of the time the macros will b= e coming from the Emacs core, the macros of which we'll annotate as safe=2E= No reason whatsoever that we shouldn't be able to expand, say, a cl-defgen= eric form in an untrusted file=2E<br><br>(We should use an oclosure instead= of a plist property so we can easily attach the attribute to macrolet macr= os too)<br><br>Probably simplest to make the safety annotation just another= declare form=2E I'd love to integrate it into edebug specs, but sadly edeb= ug doesn't have an API other components can use to extract and use the info= rmation embedded in debug specs, and current edebug syntax doesn't have all= the information we'd need for safety=2E (Oh, this macro takes a sexp? I ca= n still eval it during expansion!)<br><br>>Even better, we should have a= safe evaluation sandbox that can be used<br>>for safe macro-expansion a= mong other things=2E=C2=A0 Indeed, any solution that<br>>allows us to sa= fely expand (most) macros would be a great improvement=2E<br><br><br>>Bu= t until we have something like that, we should guard macro-expansion<br>>= ;behind trusted-content-p checks=2E<br><br>I think we need a little more nu= ance than that<br><br></div></body></html> ------EMCF8KR1KFEKRJWKYNZXRNI8RKV9CO--
X-Loop: help-debbugs@HIDDEN Subject: bug#77341: [PATCH] ; (find-function-search-for-symbol): Be cautious with macros. Resent-From: Daniel Colascione <dancol@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-gnu-emacs@HIDDEN Resent-Date: Sat, 29 Mar 2025 15:01:01 +0000 Resent-Message-ID: <handler.77341.B.174326040824022 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 77341 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eshel Yaron <me@HIDDEN> Cc: 77341 <at> debbugs.gnu.org X-Debbugs-Original-Cc: "Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>, 77341 <at> debbugs.gnu.org Received: via spool by submit <at> debbugs.gnu.org id=B.174326040824022 (code B ref -1); Sat, 29 Mar 2025 15:01:01 +0000 Received: (at submit) by debbugs.gnu.org; 29 Mar 2025 15:00:08 +0000 Received: from localhost ([127.0.0.1]:60748 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tyXfL-0006F3-Bi for submit <at> debbugs.gnu.org; Sat, 29 Mar 2025 11:00:08 -0400 Received: from lists.gnu.org ([2001:470:142::17]:45278) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1tyXfH-0006Bc-8C for submit <at> debbugs.gnu.org; Sat, 29 Mar 2025 11:00:04 -0400 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 <dancol@HIDDEN>) id 1tyXfB-0002xX-ND for bug-gnu-emacs@HIDDEN; Sat, 29 Mar 2025 10:59:57 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <dancol@HIDDEN>) id 1tyXf8-00065Y-6k for bug-gnu-emacs@HIDDEN; Sat, 29 Mar 2025 10:59:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: References:In-Reply-To:Subject:CC:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=n3eFHyP+Kl9LHo/hbSzQcFhRG+1HrEFGZRondAvq3pU=; b=WSy4N8cNQ9XQD/IAk1Bm7uojbY RiKNgurgPiM+0nP0aNv/CKWXU38s6kUZyto52bNpKlSEGLUnGWyUQdnGcKY1ICmsuK0+a/WTRQqTT qbEjjZahSRTDKMJTM0p4VwfxmvauwCufLXIdggMfAAGtbxMI1MfiFNthSsIvP+PRqmqZwawtXVoBe qmZY00UVP7HYFUNlRnO0BxcEDZ7xnQS1jsCHeqOH7gGMRBZOy61ueqBpbOSn0EqPQTcTZZ2pCfX3x 9toaooooQV04HXe8vrR6s1KMGfchLs+ZDHieBTQpD/WEBCQqJm63GOCDpe+mDy2CEWYYHXYk1HJST BjMGyxUA==; Received: from 2603-9001-4203-1ab2-ef66-22ee-8864-07c9.inf6.spectrum.com ([2603:9001:4203:1ab2:ef66:22ee:8864:7c9]:46928 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from <dancol@HIDDEN>) id 1tyXeg-004QAb-1J; Sat, 29 Mar 2025 10:59:26 -0400 Date: Sat, 29 Mar 2025 10:59:49 -0400 From: Daniel Colascione <dancol@HIDDEN> User-Agent: K-9 Mail for Android In-Reply-To: <m1h63cconx.fsf@HIDDEN> References: <m1bjtl6p5l.fsf@HIDDEN> <4CA9F756-3DE4-461F-BABC-2FC0E629755D@HIDDEN> <m1h63cconx.fsf@HIDDEN> Message-ID: <2286A4A5-8E75-4D95-939C-7BEE3B2C580F@HIDDEN> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=----EMCF8KR1KFEKRJWKYNZXRNI8RKV9CO Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2600:3c01:e000:3d8::1; envelope-from=dancol@HIDDEN; helo=dancol.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.1 (/) ------EMCF8KR1KFEKRJWKYNZXRNI8RKV9CO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On March 29, 2025 2:54:26 AM EDT, Eshel Yaron <me@eshelyaron=2Ecom> wrote: >Daniel Colascione <dancol@dancol=2Eorg> writes: > >> On March 28, 2025 1:28:06 PM EDT, Eshel Yaron wrote: >>>Tags: patch >>> >>>find-function may expand Lisp macros in a source file when it fails to >>>find a definition otherwise=2E This patch restricts this fallback to >>>trusted buffers only, to protect against possibly harmful macros=2E >> >> I get not wanting to execute code from random files I'm just visiting, >> but if I've already actually evaluated a macro function and installed >> it in my Emacs function namespace as something I can call, is it all >> that dangerous to call it?=20 > >find-function searches through code you haven't evaluated/loaded too=2E >Even for loaded libraries, the source file/buffer contents may be >different than the loaded code=2E Either way, if you trust some files, >you can add them to trusted-content=2E If you haven't, that means they >are untrusted=2E > >In general, as long as macro-expansion remains unsafe, we should avoid >expanding untrusted macros in commands that merely edit/browse Lisp code >(in contrast with compiling/evaluating it)=2E > >> Instead of a blanket prohibition on macro expansion, > >(To be clear, I wouldn't say there's a prohibition on macro expansion, >just a restriction to trusted code, similarly to proper code evaluation, >since they're not that different in practice=2E) > >> I'd rather have macros declare that they're safe to run on untrusted >> inputs, which means mostly they don't eval their arguments=2E > >Yes, please :) Macros are just transformers from lists to lists=2E If a macro doesn't exe= cute its input data, you can pass radioactive waste through it just fine=2E= If we can trust a macro to handle untrusted data safely, we don't need to = trust its inputs=2E It should work like this: 1) presumptively, expansion of a trusted form is safe no matter which macr= o is doing the expanding=20 2) by default, expansion of untrusted forms is unsafe=20 3) however, #2 can be overridden if a macro declares (probably via oclosur= e slot) "I am safely process untrusted input" Now we can expand most macros in practice even in untrusted code because m= ost of the time the macros will be coming from the Emacs core, the macros o= f which we'll annotate as safe=2E No reason whatsoever that we shouldn't be= able to expand, say, a cl-defgeneric form in an untrusted file=2E (We should use an oclosure instead of a plist property so we can easily at= tach the attribute to macrolet macros too) Probably simplest to make the safety annotation just another declare form= =2E I'd love to integrate it into edebug specs, but sadly edebug doesn't ha= ve an API other components can use to extract and use the information embed= ded in debug specs, and current edebug syntax doesn't have all the informat= ion we'd need for safety=2E (Oh, this macro takes a sexp? I can still eval = it during expansion!) >Even better, we should have a safe evaluation sandbox that can be used >for safe macro-expansion among other things=2E Indeed, any solution that >allows us to safely expand (most) macros would be a great improvement=2E >But until we have something like that, we should guard macro-expansion >behind trusted-content-p checks=2E I think we need a little more nuance than that ------EMCF8KR1KFEKRJWKYNZXRNI8RKV9CO Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE html><html><body><div dir=3D"auto"><br><br>On March 29, 2025 2:54= :26 AM EDT, Eshel Yaron <me@eshelyaron=2Ecom> wrote:<br>>Daniel Co= lascione <dancol@dancol=2Eorg> writes:<br>><br>>> On March 2= 8, 2025 1:28:06 PM EDT, Eshel Yaron wrote:<br>>>>Tags: patch<br>&g= t;>><br>>>>find-function may expand Lisp macros in a source = file when it fails to<br>>>>find a definition otherwise=2E=C2=A0 T= his patch restricts this fallback to<br>>>>trusted buffers only, t= o protect against possibly harmful macros=2E<br>>><br>>> I get = not wanting to execute code from random files I'm just visiting,<br>>>= ; but if I've already actually evaluated a macro function and installed<br>= >> it in my Emacs function namespace as something I can call, is it a= ll<br>>> that dangerous to call it? <br>><br>>find-function sea= rches through code you haven't evaluated/loaded too=2E<br>>Even for load= ed libraries, the source file/buffer contents may be<br>>different than = the loaded code=2E=C2=A0 Either way, if you trust some files,<br>>you ca= n add them to trusted-content=2E=C2=A0 If you haven't, that means they<br>&= gt;are untrusted=2E<br>><br>>In general, as long as macro-expansion r= emains unsafe, we should avoid<br>>expanding untrusted macros in command= s that merely edit/browse Lisp code<br>>(in contrast with compiling/eval= uating it)=2E<br>><br>>> Instead of a blanket prohibition on macro= expansion,<br>><br>>(To be clear, I wouldn't say there's a prohibiti= on on macro expansion,<br>>just a restriction to trusted code, similarly= to proper code evaluation,<br>>since they're not that different in prac= tice=2E)<br>><br>>> I'd rather have macros declare that they're sa= fe to run on untrusted<br>>> inputs, which means mostly they don't ev= al their arguments=2E<br>><br>>Yes, please :)<br><br><br>Macros are j= ust transformers from lists to lists=2E If a macro doesn't execute its inpu= t data, you can pass radioactive waste through it just fine=2E If we can tr= ust a macro to handle untrusted data safely, we don't need to trust its inp= uts=2E<br><br>It should work like this:<br><br>1) presumptively, expansion = of a trusted form is safe no matter which macro is doing the expanding <br>= <br>2) by default, expansion of untrusted forms is unsafe <br><br>3) howeve= r, #2 can be overridden if a macro declares (probably via oclosure slot) "I= am safely process untrusted input"<br><br>Now we can expand most macros in= practice even in untrusted code because most of the time the macros will b= e coming from the Emacs core, the macros of which we'll annotate as safe=2E= No reason whatsoever that we shouldn't be able to expand, say, a cl-defgen= eric form in an untrusted file=2E<br><br>(We should use an oclosure instead= of a plist property so we can easily attach the attribute to macrolet macr= os too)<br><br>Probably simplest to make the safety annotation just another= declare form=2E I'd love to integrate it into edebug specs, but sadly edeb= ug doesn't have an API other components can use to extract and use the info= rmation embedded in debug specs, and current edebug syntax doesn't have all= the information we'd need for safety=2E (Oh, this macro takes a sexp? I ca= n still eval it during expansion!)<br><br>>Even better, we should have a= safe evaluation sandbox that can be used<br>>for safe macro-expansion a= mong other things=2E=C2=A0 Indeed, any solution that<br>>allows us to sa= fely expand (most) macros would be a great improvement=2E<br><br><br>>Bu= t until we have something like that, we should guard macro-expansion<br>>= ;behind trusted-content-p checks=2E<br><br>I think we need a little more nu= ance than that<br><br></div></body></html> ------EMCF8KR1KFEKRJWKYNZXRNI8RKV9CO--
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.