From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers Date: Tue, 17 Dec 2024 12:30:14 +0100 Message-ID: <87h6721r95.fsf@daniel-mendler.de> References: <87ed29ixu8.fsf@daniel-mendler.de> <875xnlfdzi.fsf@daniel-mendler.de> <643a50f9-2128-405b-ae5b-114990b3dfc2@gutov.dev> <87h6739245.fsf@daniel-mendler.de> Reply-To: Daniel Mendler Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28677"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 74879@debbugs.gnu.org, Stefan Monnier , Stefan Kangas To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 17 12:31:21 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tNVnN-0007HI-90 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 17 Dec 2024 12:31:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tNVnA-0002Ki-6C; Tue, 17 Dec 2024 06:31:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tNVn4-0002K9-V6 for bug-gnu-emacs@gnu.org; Tue, 17 Dec 2024 06:31:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tNVn4-000856-AB for bug-gnu-emacs@gnu.org; Tue, 17 Dec 2024 06:31:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=XcvynM3dOnHGEbB3CvB32Ecrk6v/jaO/9vXjITOoaWw=; b=U6cY9B4DUkkFxpCwb4stD7VwEeAZ1v3TntEpSn/Lsw64MBJhMiyrBQ19d0XADOcVl9HZgT2LR5XB64WrHweLsQMo7BYUgvaLvVyQTPvGbMzUQ8jDqJw9Y6cDAewbodxKoQg+F0l+aRhc/Z1fmLYzm5sku3zfyKd4ZSRYYBKfOG2eUPOW/eW+aJ5G4PE6IK2U2ILMOFxtCipKVKe+t0JO2H+Jkh8xaVJtOGgRnCyuilOqwBBI/HL1HSa09YY90XznSs1YUzeosKEH8RA3efrFecFzJPIsx3H6JDbO6QL9d0plm5O5+aYE7AuFdXZmxQeV1p2/4SzNQVze9aU8KkpVjA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tNVn3-0002GJ-Rz for bug-gnu-emacs@gnu.org; Tue, 17 Dec 2024 06:31:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 17 Dec 2024 11:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74879 X-GNU-PR-Package: emacs Original-Received: via spool by 74879-submit@debbugs.gnu.org id=B74879.17344350298626 (code B ref 74879); Tue, 17 Dec 2024 11:31:01 +0000 Original-Received: (at 74879) by debbugs.gnu.org; 17 Dec 2024 11:30:29 +0000 Original-Received: from localhost ([127.0.0.1]:57798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tNVmV-0002Ex-Qb for submit@debbugs.gnu.org; Tue, 17 Dec 2024 06:30:28 -0500 Original-Received: from server.qxqx.de ([49.12.34.165]:51465 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tNVmQ-00029S-Gm for 74879@debbugs.gnu.org; Tue, 17 Dec 2024 06:30:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding: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=XcvynM3dOnHGEbB3CvB32Ecrk6v/jaO/9vXjITOoaWw=; b=Td9076SawdHAgMtX1VDGNkfOYg nyr3sxtX+HvSmgkfR1r6xKCsltU9hTPDusWqk/Obtt3pIaGc5vQb3JB35Glrx1SmfOmKTER8v6y8j mQAELenBTxSZ9hoSD96tVT8EUICeNkCFE1Xvx9Gf65SYQEj+f350ANh08iGd3xK0pze0=; In-Reply-To: (Dmitry Gutov's message of "Tue, 17 Dec 2024 03:42:16 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:297267 Archived-At: Dmitry Gutov writes: > And with code completion they press C-M-i - which is something people do > regularly as well. It wouldn't really matter than auto-completion handler runs > once per input while you only press C-M-i once per minute, or even once per > hour. To compromise a system or the user's data (this is what we're talking > about, right?), it only needs to happen once. > > I don't imagine we're going to slap a "there be dragons" warning on every > auto-completion option, and on 'completion-at-point' either. I don't disagree with your points. For me the issue here has been solved satisfactorily given Stefan's recent changes in the emacs-30 branch, such that the trust facilities can be used in non-file buffers. As for the usefulness of the trust feature - I think one can use it for both disabling certain dangerous code like macro expansion to close a security hole, and also to adjust confirmation settings in user configurations. For example in trusted buffers or trusted files confirmation a user might want to execute Org babel or Org links directly, while this should not happen in downloaded files or buffers coming from Gnus. While disabling confirmation decreases security, disabling confirmation only in trusted buffers is still better than disabling confirmation globally. The same applies to file-local variables. In trusted files, one may want to activate file-local variables always or with confirmation, while in untrusted files, local variables should be disabled entirely or only :safe variables should be loaded. Daniel