Received: (at submit) by debbugs.gnu.org; 29 Mar 2025 15:00:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 29 11:00:08 2025 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> To: Eshel Yaron <me@HIDDEN> Subject: =?US-ASCII?Q?Re=3A_bug=2377341=3A_=5BPATCH=5D_=3B_=28find-function-se?= =?US-ASCII?Q?arch-for-symbol=29=3A_Be_cautious_with_macros=2E?= 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-Debbugs-Envelope-To: submit 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 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--
bug-gnu-emacs@HIDDEN:bug#77341; Package emacs.
Full text available.Received: (at 77341) by debbugs.gnu.org; 29 Mar 2025 14:59:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 29 10:59:58 2025 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> To: Eshel Yaron <me@HIDDEN> Subject: =?US-ASCII?Q?Re=3A_bug=2377341=3A_=5BPATCH=5D_=3B_=28find-function-se?= =?US-ASCII?Q?arch-for-symbol=29=3A_Be_cautious_with_macros=2E?= 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-Debbugs-Envelope-To: 77341 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 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--
bug-gnu-emacs@HIDDEN:bug#77341; Package emacs.
Full text available.Received: (at 77341) by debbugs.gnu.org; 29 Mar 2025 06:54:34 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 29 02:54:34 2025 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> To: Daniel Colascione <dancol@HIDDEN> Subject: Re: bug#77341: [PATCH] ; (find-function-search-for-symbol): Be cautious with macros. 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-Debbugs-Envelope-To: 77341 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 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
bug-gnu-emacs@HIDDEN:bug#77341; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 29 Mar 2025 06:54:41 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 29 02:54:40 2025 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> To: Daniel Colascione <dancol@HIDDEN> Subject: Re: bug#77341: [PATCH] ; (find-function-search-for-symbol): Be cautious with macros. 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-Debbugs-Envelope-To: submit 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 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
bug-gnu-emacs@HIDDEN:bug#77341; Package emacs.
Full text available.Received: (at 77341) by debbugs.gnu.org; 28 Mar 2025 19:43:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 28 15:43:47 2025 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> 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 Subject: =?US-ASCII?Q?Re=3A_bug=2377341=3A_=5BPATCH=5D_=3B_=28find-function-se?= =?US-ASCII?Q?arch-for-symbol=29=3A_Be_cautious_with_macros=2E?= 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-Debbugs-Envelope-To: 77341 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
bug-gnu-emacs@HIDDEN:bug#77341; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 28 Mar 2025 19:43:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 28 15:43:53 2025 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> 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 Subject: =?US-ASCII?Q?Re=3A_bug=2377341=3A_=5BPATCH=5D_=3B_=28find-function-se?= =?US-ASCII?Q?arch-for-symbol=29=3A_Be_cautious_with_macros=2E?= 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-Debbugs-Envelope-To: submit 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
bug-gnu-emacs@HIDDEN:bug#77341; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 28 Mar 2025 17:28:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 28 13:28:24 2025
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>
To: bug-gnu-emacs@HIDDEN
Subject: [PATCH] ; (find-function-search-for-symbol): Be cautious with macros.
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-Debbugs-Envelope-To: submit
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
--=-=-=--
Eshel Yaron <me@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#77341; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.