GNU logs - #77341, boring messages

Message sent to bug-gnu-emacs@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
To: 77341 <at> debbugs.gnu.org
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

--=-=-=--

Message sent:

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

Message sent to bug-gnu-emacs@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
To: me@HIDDEN, 77341 <at> debbugs.gnu.org
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

Message sent to bug-gnu-emacs@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
To: me@HIDDEN, 77341 <at> debbugs.gnu.org
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
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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

Message sent to bug-gnu-emacs@HIDDEN:

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

Message sent to bug-gnu-emacs@HIDDEN:

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

Message sent to bug-gnu-emacs@HIDDEN:

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 &lt;me@eshelyaron=2Ecom&gt; wrote:<br>&gt;Daniel Co=
lascione &lt;dancol@dancol=2Eorg&gt; writes:<br>&gt;<br>&gt;&gt; On March 2=
8, 2025 1:28:06 PM EDT, Eshel Yaron wrote:<br>&gt;&gt;&gt;Tags: patch<br>&g=
t;&gt;&gt;<br>&gt;&gt;&gt;find-function may expand Lisp macros in a source =
file when it fails to<br>&gt;&gt;&gt;find a definition otherwise=2E=C2=A0 T=
his patch restricts this fallback to<br>&gt;&gt;&gt;trusted buffers only, t=
o protect against possibly harmful macros=2E<br>&gt;&gt;<br>&gt;&gt; I get =
not wanting to execute code from random files I'm just visiting,<br>&gt;&gt=
; but if I've already actually evaluated a macro function and installed<br>=
&gt;&gt; it in my Emacs function namespace as something I can call, is it a=
ll<br>&gt;&gt; that dangerous to call it? <br>&gt;<br>&gt;find-function sea=
rches through code you haven't evaluated/loaded too=2E<br>&gt;Even for load=
ed libraries, the source file/buffer contents may be<br>&gt;different than =
the loaded code=2E=C2=A0 Either way, if you trust some files,<br>&gt;you ca=
n add them to trusted-content=2E=C2=A0 If you haven't, that means they<br>&=
gt;are untrusted=2E<br>&gt;<br>&gt;In general, as long as macro-expansion r=
emains unsafe, we should avoid<br>&gt;expanding untrusted macros in command=
s that merely edit/browse Lisp code<br>&gt;(in contrast with compiling/eval=
uating it)=2E<br>&gt;<br>&gt;&gt; Instead of a blanket prohibition on macro=
 expansion,<br>&gt;<br>&gt;(To be clear, I wouldn't say there's a prohibiti=
on on macro expansion,<br>&gt;just a restriction to trusted code, similarly=
 to proper code evaluation,<br>&gt;since they're not that different in prac=
tice=2E)<br>&gt;<br>&gt;&gt; I'd rather have macros declare that they're sa=
fe to run on untrusted<br>&gt;&gt; inputs, which means mostly they don't ev=
al their arguments=2E<br>&gt;<br>&gt;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>&gt;Even better, we should have a=
 safe evaluation sandbox that can be used<br>&gt;for safe macro-expansion a=
mong other things=2E=C2=A0 Indeed, any solution that<br>&gt;allows us to sa=
fely expand (most) macros would be a great improvement=2E<br><br><br>&gt;Bu=
t until we have something like that, we should guard macro-expansion<br>&gt=
;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--

Message sent to bug-gnu-emacs@HIDDEN:

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 &lt;me@eshelyaron=2Ecom&gt; wrote:<br>&gt;Daniel Co=
lascione &lt;dancol@dancol=2Eorg&gt; writes:<br>&gt;<br>&gt;&gt; On March 2=
8, 2025 1:28:06 PM EDT, Eshel Yaron wrote:<br>&gt;&gt;&gt;Tags: patch<br>&g=
t;&gt;&gt;<br>&gt;&gt;&gt;find-function may expand Lisp macros in a source =
file when it fails to<br>&gt;&gt;&gt;find a definition otherwise=2E=C2=A0 T=
his patch restricts this fallback to<br>&gt;&gt;&gt;trusted buffers only, t=
o protect against possibly harmful macros=2E<br>&gt;&gt;<br>&gt;&gt; I get =
not wanting to execute code from random files I'm just visiting,<br>&gt;&gt=
; but if I've already actually evaluated a macro function and installed<br>=
&gt;&gt; it in my Emacs function namespace as something I can call, is it a=
ll<br>&gt;&gt; that dangerous to call it? <br>&gt;<br>&gt;find-function sea=
rches through code you haven't evaluated/loaded too=2E<br>&gt;Even for load=
ed libraries, the source file/buffer contents may be<br>&gt;different than =
the loaded code=2E=C2=A0 Either way, if you trust some files,<br>&gt;you ca=
n add them to trusted-content=2E=C2=A0 If you haven't, that means they<br>&=
gt;are untrusted=2E<br>&gt;<br>&gt;In general, as long as macro-expansion r=
emains unsafe, we should avoid<br>&gt;expanding untrusted macros in command=
s that merely edit/browse Lisp code<br>&gt;(in contrast with compiling/eval=
uating it)=2E<br>&gt;<br>&gt;&gt; Instead of a blanket prohibition on macro=
 expansion,<br>&gt;<br>&gt;(To be clear, I wouldn't say there's a prohibiti=
on on macro expansion,<br>&gt;just a restriction to trusted code, similarly=
 to proper code evaluation,<br>&gt;since they're not that different in prac=
tice=2E)<br>&gt;<br>&gt;&gt; I'd rather have macros declare that they're sa=
fe to run on untrusted<br>&gt;&gt; inputs, which means mostly they don't ev=
al their arguments=2E<br>&gt;<br>&gt;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>&gt;Even better, we should have a=
 safe evaluation sandbox that can be used<br>&gt;for safe macro-expansion a=
mong other things=2E=C2=A0 Indeed, any solution that<br>&gt;allows us to sa=
fely expand (most) macros would be a great improvement=2E<br><br><br>&gt;Bu=
t until we have something like that, we should guard macro-expansion<br>&gt=
;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--

Message sent to bug-gnu-emacs@HIDDEN:

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, 05 Apr 2025 06:30:02 +0000
Resent-Message-ID: <handler.77341.B77341.174383457917338 <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
Received: via spool by 77341-submit <at> debbugs.gnu.org id=B77341.174383457917338
          (code B ref 77341); Sat, 05 Apr 2025 06:30:02 +0000
Received: (at 77341) by debbugs.gnu.org; 5 Apr 2025 06:29:39 +0000
Received: from localhost ([127.0.0.1]:41251 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1u0x2A-0004VZ-9K
	for submit <at> debbugs.gnu.org; Sat, 05 Apr 2025 02:29:38 -0400
Received: from mail.eshelyaron.com ([107.175.124.16]:43206 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 1u0x27-0004VM-4L; Sat, 05 Apr 2025 02:29:35 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com;
 s=mail; t=1743834574;
 bh=dPj0kVaY+Eso7Yw4OCnSncgx1q1EoVRikvQ09jiiITs=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=w5P/nqsaznFLfKH8XBbyErT0ncljcbn+70Pxf/VTpyCUKpzu9cbG4q1Q1FuTR5C1e
 BynL1leKYPGwtYcb3AoKtd8Y9C/cX25bDQCGuG26JkzAvTlTI/xmzNEzf/vN/rOxFz
 q3Xhz68WQwE4DvOA1HE8xdqG/TAt4mQmzOyORDHrjsNJttMl89vppiw1nFhTtqkwxq
 YREQQKAjRKYq4TzsVwsrJnKpd7OnKqFLJezM4DwLI72KzGyoAzpKTM6ONq2TJkeVOd
 E8iEROKqo7onaEUCVlGw9X/5RkVcUXeDDUTPIEMs4+rR9gSmNGpCn0JJZDLguuwBxe
 70j15KZKFcswg==
From: Eshel Yaron <me@HIDDEN>
In-Reply-To: <2286A4A5-8E75-4D95-939C-7BEE3B2C580F@HIDDEN>
References: <m1bjtl6p5l.fsf@HIDDEN>
 <4CA9F756-3DE4-461F-BABC-2FC0E629755D@HIDDEN>
 <m1h63cconx.fsf@HIDDEN>
 <2286A4A5-8E75-4D95-939C-7BEE3B2C580F@HIDDEN>
Date: Sat, 05 Apr 2025 08:29:31 +0200
Message-ID: <m1semnce9g.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 (-)

close 77341 31.1
quit

Hi Daniel,

Daniel Colascione <dancol@HIDDEN> writes:

> On March 29, 2025 2:54:26 AM EDT, Eshel Yaron <me@HIDDEN> wrote:
>>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 :)
>
> Macros are just transformers from lists to lists. If a macro doesn't
> execute its input data, you can pass radioactive waste through it just
> fine.

Well, in practice macros can do literally anything at the moment,
including doing nasty things when given certain inputs, even without
executing the input directly...

> If we can trust a macro to handle untrusted data safely, we don't need
> to trust its inputs.

Agreed.

> It should work like this:
>
> 1) presumptively, expansion of a trusted form is safe no matter which macro is doing the expanding 
>
> 2) by default, expansion of untrusted forms is unsafe 
>
> 3) however, #2 can be overridden if a macro declares (probably via oclosure slot) "I am safely process untrusted
> input"
>
> Now we can expand most macros in practice even in untrusted code because most of the time the macros will be
> coming from the Emacs core, the macros of which we'll annotate as safe. No reason whatsoever that we shouldn't
> be able to expand, say, a cl-defgeneric form in an untrusted file.
>
> (We should use an oclosure instead of a plist property so we can easily attach the attribute to macrolet macros
> too)
>
> Probably simplest to make the safety annotation just another declare form. I'd love to integrate it into edebug
> specs, but sadly edebug doesn't have an API other components can use to extract and use the information embedded
> in debug specs, and current edebug syntax doesn't have all the information we'd need for safety. (Oh, this macro
> takes a sexp? I can still eval it during expansion!)

I wonder if unsafep could help with something like that.  It's not fully
developed/integrated, but ISTM to have the key notions in place, like
the side-effect-free property, that can be specified via declare forms.

>>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.
>
> I think we need a little more nuance than that

I'm not sure what you mean concretely.  As long as macro-expansion is
unrestrained (e.g. by something along the lines you've described above),
it's not safe to expand macros in untrusted code, so we should avoid it.
What nuance is missing?


Anyway, I suggest we start a separate discussion for general solutions
to safe macro-expansion -- regarding the specific case in find-function,
I've now pushed the patch, and with that, I'm closing this bug.


Thanks,

Eshel

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 5 Apr 2025 06:29:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 05 02:29:39 2025
Received: from localhost ([127.0.0.1]:41253 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1u0x2A-0004Vb-R2
	for submit <at> debbugs.gnu.org; Sat, 05 Apr 2025 02:29:39 -0400
Received: from mail.eshelyaron.com ([107.175.124.16]:43206 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 1u0x27-0004VM-4L; Sat, 05 Apr 2025 02:29:35 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com;
 s=mail; t=1743834574;
 bh=dPj0kVaY+Eso7Yw4OCnSncgx1q1EoVRikvQ09jiiITs=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=w5P/nqsaznFLfKH8XBbyErT0ncljcbn+70Pxf/VTpyCUKpzu9cbG4q1Q1FuTR5C1e
 BynL1leKYPGwtYcb3AoKtd8Y9C/cX25bDQCGuG26JkzAvTlTI/xmzNEzf/vN/rOxFz
 q3Xhz68WQwE4DvOA1HE8xdqG/TAt4mQmzOyORDHrjsNJttMl89vppiw1nFhTtqkwxq
 YREQQKAjRKYq4TzsVwsrJnKpd7OnKqFLJezM4DwLI72KzGyoAzpKTM6ONq2TJkeVOd
 E8iEROKqo7onaEUCVlGw9X/5RkVcUXeDDUTPIEMs4+rR9gSmNGpCn0JJZDLguuwBxe
 70j15KZKFcswg==
From: Eshel Yaron <me@HIDDEN>
To: Daniel Colascione <dancol@HIDDEN>
Subject: Re: bug#77341: [PATCH] ; (find-function-search-for-symbol): Be
 cautious with macros.
In-Reply-To: <2286A4A5-8E75-4D95-939C-7BEE3B2C580F@HIDDEN>
References: <m1bjtl6p5l.fsf@HIDDEN>
 <4CA9F756-3DE4-461F-BABC-2FC0E629755D@HIDDEN>
 <m1h63cconx.fsf@HIDDEN>
 <2286A4A5-8E75-4D95-939C-7BEE3B2C580F@HIDDEN>
Date: Sat, 05 Apr 2025 08:29:31 +0200
Message-ID: <m1semnce9g.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: control
Cc: 77341 <at> debbugs.gnu.org
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 (-)

close 77341 31.1
quit

Hi Daniel,

Daniel Colascione <dancol@HIDDEN> writes:

> On March 29, 2025 2:54:26 AM EDT, Eshel Yaron <me@HIDDEN> wrote:
>>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 :)
>
> Macros are just transformers from lists to lists. If a macro doesn't
> execute its input data, you can pass radioactive waste through it just
> fine.

Well, in practice macros can do literally anything at the moment,
including doing nasty things when given certain inputs, even without
executing the input directly...

> If we can trust a macro to handle untrusted data safely, we don't need
> to trust its inputs.

Agreed.

> It should work like this:
>
> 1) presumptively, expansion of a trusted form is safe no matter which macro is doing the expanding 
>
> 2) by default, expansion of untrusted forms is unsafe 
>
> 3) however, #2 can be overridden if a macro declares (probably via oclosure slot) "I am safely process untrusted
> input"
>
> Now we can expand most macros in practice even in untrusted code because most of the time the macros will be
> coming from the Emacs core, the macros of which we'll annotate as safe. No reason whatsoever that we shouldn't
> be able to expand, say, a cl-defgeneric form in an untrusted file.
>
> (We should use an oclosure instead of a plist property so we can easily attach the attribute to macrolet macros
> too)
>
> Probably simplest to make the safety annotation just another declare form. I'd love to integrate it into edebug
> specs, but sadly edebug doesn't have an API other components can use to extract and use the information embedded
> in debug specs, and current edebug syntax doesn't have all the information we'd need for safety. (Oh, this macro
> takes a sexp? I can still eval it during expansion!)

I wonder if unsafep could help with something like that.  It's not fully
developed/integrated, but ISTM to have the key notions in place, like
the side-effect-free property, that can be specified via declare forms.

>>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.
>
> I think we need a little more nuance than that

I'm not sure what you mean concretely.  As long as macro-expansion is
unrestrained (e.g. by something along the lines you've described above),
it's not safe to expand macros in untrusted code, so we should avoid it.
What nuance is missing?


Anyway, I suggest we start a separate discussion for general solutions
to safe macro-expansion -- regarding the specific case in find-function,
I've now pushed the patch, and with that, I'm closing this bug.


Thanks,

Eshel

Last modified: Sat, 5 Apr 2025 06:45:01 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.