Eshel Yaron <me@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 77341) by debbugs.gnu.org; 5 Apr 2025 06:29:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 05 02:29:38 2025 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> 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: 77341 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
bug-gnu-emacs@HIDDEN:bug#77341; Package emacs.
Full text available.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.