From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier 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 09:43:54 -0500 Message-ID: References: <87ed29ixu8.fsf@daniel-mendler.de> <87msgw94fz.fsf@daniel-mendler.de> <87v7vk562i.fsf@daniel-mendler.de> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22802"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 74879@debbugs.gnu.org To: Daniel Mendler Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 16 15:45: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 1tNCLT-0005gD-Vi for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Dec 2024 15:45:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tNCLI-0007Za-4k; Mon, 16 Dec 2024 09:45:04 -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 1tNCLG-0007ZQ-Uj for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 09:45: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 1tNCLG-0004C6-Kl for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 09:45: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=pyPd+oedfSANnReGwOQxVpClrOhw0oldH7W/qG4PECU=; b=f/EPWsYw7IrMY2JpH2hSKjR0nfrAGhOtL6PzjeV33zOVTdA9rwbF+vIFK4xIwuJ1gUOXVYjgG5ZurSKh17LMJdZW0lEYuCsq6kDly/I2BI4dqcF61TW50758lIcAUZ2fRUUZioMz5YXxU4+xMqEwn++qO40Lklq1yHa9C1Uk7sGvAMyrt6vrS1KT5guwL6z5fwvvb8NUqbmSuD+OzdfpoJxaidWoDAJBknMlZ7tujyeGasB30xbp3o12qoi4Sc+Jwlaakvb2iNTclYyM4HoTGT4OYwifYYbccGnO+C5kZYRQD7woax7TM9U4/77ibqjchHmivSNjDkK3NhenRLJEGA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tNCLG-0005Nh-E1 for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 09:45:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Dec 2024 14:45:02 +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.173436024620574 (code B ref 74879); Mon, 16 Dec 2024 14:45:02 +0000 Original-Received: (at 74879) by debbugs.gnu.org; 16 Dec 2024 14:44:06 +0000 Original-Received: from localhost ([127.0.0.1]:54095 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tNCKL-0005Lm-Q8 for submit@debbugs.gnu.org; Mon, 16 Dec 2024 09:44:06 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42774) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tNCKJ-0005L8-3R for 74879@debbugs.gnu.org; Mon, 16 Dec 2024 09:44:04 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 427341000BD; Mon, 16 Dec 2024 09:43:57 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1734360236; bh=L6+6X39pcqpdyZ9APiRw33DQ1z9iHs6gdnyiPnJ2h78=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=obDNpcmdxg+mVUCPdvH7XvUrDrCPwIXUmqMpEx0f8nP+3KsZcAG6oR66iwa5sgh6P LLAIcvnlYixinIdsGkW7328MRF7x1bbYVFdh3KzQve2b5TQSltRm1UokvaxULT5+KU JzK5bswMCTLCWqKgB1gPEw5AMGm3g9nbnO3+BpfDLgOqVjdTItNtocqJNm0YSbOYCR TdaxHQZ5WpBgxs58NeM5uH9T4ySAqwMdfYgc1nva5dnTsrRTpejZ3iqY5AjTpBb4oD IXBSZ3FMZP16IDDUf8LSIbNA9tbHH4deAB6VDAtdE9aNfaqmFXtJ04jDB2pgEILtDV 5tp6D7KlbdxoQ== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5D8BD100042; Mon, 16 Dec 2024 09:43:56 -0500 (EST) Original-Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 32437120611; Mon, 16 Dec 2024 09:43:56 -0500 (EST) In-Reply-To: <87v7vk562i.fsf@daniel-mendler.de> (Daniel Mendler's message of "Mon, 16 Dec 2024 10:29:41 +0100") 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:297172 Archived-At: >> I can live with that for now. >> It's probably not much worse than >> >> (add-function :override (local 'trusted-content-function) #'always) >> >> [ BTW, I just renamed the var to `trusted-content`. ] > > I think it is not as good as a central configuration variable where I > configure the trust for buffers or files. Now configuring trust is > scattered across multiple major modes. My proposal was for a global hook > variable which is consulted by `trusted-content-p' and then checks > certain trust list for files or buffers. This way it is easier to check > what we are trusting. Both `trusted-content-function` and `trusted-content-functions` would be "normal" hooks in the sense that they are neither specifically global nor specifically local: the code that adds elements to it get to choose whether to add it buffer-locally or globally. For major modes, it makes a lot more sense to add elements locally, since that avoids having to worry about the performance impact on the rest of Emacs and things like that. > 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. What kind of situation are you thinking of where completion is unsafe? > My initial proposal was about a global `trusted-buffer-functions' hook I don't see any reason to restrict such a hook to be global. > but I may have not communicated this clearly enough. I have two problems > with the buffer-local approach: The `trusted-buffer-function` I sketched would similarly not be restricted to be buffer-local. IOW local/global is orthogonal to whether we go with `trusted-buffer-functions` or `trusted-buffer-function`. > 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`. > 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. Stefan