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: Mon, 16 Dec 2024 19:48:44 +0100 Message-ID: <87jzbz79bn.fsf@daniel-mendler.de> References: <87ed29ixu8.fsf@daniel-mendler.de> <87msgw94fz.fsf@daniel-mendler.de> <87v7vk562i.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="38114"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 74879@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 16 19:49:16 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 1tNG9c-0009kF-5O for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Dec 2024 19:49:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tNG9R-0005wZ-EY; Mon, 16 Dec 2024 13:49:05 -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 1tNG9O-0005wA-LX for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 13:49: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 1tNG9O-0007WK-AX for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 13:49: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=MRYXb5Ge82C1fzS/xqWzj6kfeSwkMfvO5LrLkNms724=; b=SerT5sZfOEJK68OFZQSosLhCMYVcANhtBuCkA5vot+pmF5bDPw67/lpOIzj5sPuXU64YySS7O3JSkBZyIjIH2RlVI5lxYyaKFzAKG1fRvjDF4caPAWz0+7A9i16aXF7OruD+5aXp362PEgaYLvJMu14pS5lkJVeE8NU79aDJwFAuOTYs0yjZo2MCEI0RsDgr+Ne6kclmfzQcbZcsWTlLGV8L0iuUjTd0H3E1a7e54nd72SAsETF6dNZR/7209weVfWNw4/3jSJ9UdS0a8tNdD8y1J4dIriuOu0b9vzx/dgIYW89Wzwu/2pQ6F1os2GrHFIVU4adgkcnaGBvNK4MkGQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tNG9N-0002Se-Sf for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 13:49: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: Mon, 16 Dec 2024 18:49: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.17343749369445 (code B ref 74879); Mon, 16 Dec 2024 18:49:01 +0000 Original-Received: (at 74879) by debbugs.gnu.org; 16 Dec 2024 18:48:56 +0000 Original-Received: from localhost ([127.0.0.1]:56175 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tNG9H-0002SG-QC for submit@debbugs.gnu.org; Mon, 16 Dec 2024 13:48:56 -0500 Original-Received: from server.qxqx.de ([49.12.34.165]:60891 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tNG9F-0002Rx-4r for 74879@debbugs.gnu.org; Mon, 16 Dec 2024 13:48:54 -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=MRYXb5Ge82C1fzS/xqWzj6kfeSwkMfvO5LrLkNms724=; b=DRoGj5G1HDDsoqIw3Y8kgW33kl LzUX2EYf3Rd4hDjBQ7uknajLh/5bKP8NwCbUSFbLxOCT3P4bAxuL9bmS7YbDQFKkgIrApF0OYK9fY pyn3oOW5+DsBrcaxMwQBoPVh869H+SC1Vmvo7lcHyKgjp8/kwG63nUqVMUvCKRV3/sJw=; In-Reply-To: (Stefan Monnier's message of "Mon, 16 Dec 2024 09:43:54 -0500") 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:297212 Archived-At: Stefan Monnier writes: >> The thought was rather that auto completion may be dangerous in general > > Maybe I have too narrow a view of completion, but my impression is that > completion is usually safe. The situation in ELisp where we perform > macro expansion to try and get the set of local variables in scope and > where that macro expansion can end up running local code is rather > unusual, AFAIK. Agree. > What kind of situation are you thinking of where completion is unsafe? Elisp completion on Emacs 29 and older for example ;) >> I just took another look at the `trusted-content-p' function on the >> emacs-30 branch: >> >> (defun trusted-content-p () >> (and (not untrusted-content) >> buffer-file-truename >> ...)) >> >> There is a check for `buffer-file-truename' which means that the issue >> with non-file-backed buffers remains (Ielm or scratch). Probably (eq >> trusted-content :all) should be checked first? > > Duh! I forgot that the same change toned down the warnings, so I > didn't look at the right place when "testing". Thanks for the heads up, > I just fixed it in `emacs-30`. Thanks for pushing the fix. >> At the same time one could consolidate the untrusted-content and >> trusted-content variables as Eshel suggested? >> >> (defun trusted-content-p () >> (and (not untrusted-content) ;; only for backward compat (deprecated) >> (not (eq trusted-content :untrusted)) ;; replaces untrusted-content >> (or (eq trusted-content :all) >> (and buffer-file-name >> ...)))) > > I could go along with that (not for `emacs-30`, tho). > I'd prefer to get a bit more experience before deciding to do that, tho. Okay, sure. No urgency about that one. Just to give some examples where the new trust function could be useful, assuming that the user really trusts their trusted files: (setq org-confirm-babel-evaluate (lambda (&rest _) (not (trusted-content-p))) org-link-elisp-confirm-function (lambda (prompt) (or (trusted-content-p) (y-or-n-p prompt))) org-link-shell-confirm-function org-link-elisp-confirm-function) Maybe it is possible to configure `enable-local-variables' similarly. Daniel