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: Sun, 15 Dec 2024 19:38:56 +0100 Message-ID: <87msgw94fz.fsf@daniel-mendler.de> References: <87ed29ixu8.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="23835"; 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 Sun Dec 15 19:42:29 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 1tMtZT-00063Y-Ur for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 15 Dec 2024 19:42:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tMtZG-0004QM-G0; Sun, 15 Dec 2024 13:42:14 -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 1tMtZ6-0004Pj-3W for bug-gnu-emacs@gnu.org; Sun, 15 Dec 2024 13:42:06 -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 1tMtZ5-0006Qn-RY for bug-gnu-emacs@gnu.org; Sun, 15 Dec 2024 13:42:03 -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=Q7OLyG5AdoTM4gDM2TRKSNbKLflLZzL1oGpcgRAQSps=; b=f93FeB/19Z7Cp5OtOoF0iqeTjF+dMSAUV10ftYcXWEl2gsi8kI2PLonauYXwKRfJtQeRx+TA6S5S6eQe99RjicrEtqHMIoYhVugXPKU+Ib5P8Qt0eTSowh0FoVLXZwIla2cL41wgKhE/6ckwxKcFbnQKjNAyB0JRtpOe20mVlClV+ZZE/jA2Wh7jePPe+j0NkhG1hbR9w7hg6E/n7qXCIWdZ2X9icAW9eETZxYMxyVOCXUgUyJhWnLp9BX5oV7uYW59mZDnH1SW1SfGfJ/MR1FmEEY4mQnA3cjuNmrpl1IqKvKqpsItyDOD3KVlTBfAD5bsz9pSReSbZHhAf9zKMNg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tMtZ4-0004aH-GS for bug-gnu-emacs@gnu.org; Sun, 15 Dec 2024 13:42: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: Sun, 15 Dec 2024 18:42: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.173428808017549 (code B ref 74879); Sun, 15 Dec 2024 18:42:02 +0000 Original-Received: (at 74879) by debbugs.gnu.org; 15 Dec 2024 18:41:20 +0000 Original-Received: from localhost ([127.0.0.1]:52042 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tMtYN-0004Yw-04 for submit@debbugs.gnu.org; Sun, 15 Dec 2024 13:41:19 -0500 Original-Received: from server.qxqx.de ([49.12.34.165]:45141 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tMtYK-0004Yb-TW for 74879@debbugs.gnu.org; Sun, 15 Dec 2024 13:41:18 -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=Q7OLyG5AdoTM4gDM2TRKSNbKLflLZzL1oGpcgRAQSps=; b=JA+HdDDdkmIj9fnz3RFjvHGTzi LnjVYWEmc/0DYmhwpWQCk4HU/mxqsJIuGzCqKg66rBuy3JIDWdsC+MVvlVB0mAzib5YC7ABctKZT0 ao4z8Q+RzI0caSWTUWp3UT6vB36xWkZJm2MO6YQKyhjjhEeRHXpP29pDrAFUbjkQW9zI=; In-Reply-To: (Stefan Monnier's message of "Sun, 15 Dec 2024 09:03:18 -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:297122 Archived-At: Stefan Monnier writes: >> Thank you for the recent addition of `trusted-content-p'. Is there a >> possibility to use `trusted-content-p' in buffers which are not backed >> by a file? I use Flymake in *scratch* or similar buffers and it seems >> that this won't continue to work given that `trusted-content-p' needs a >> `buffer-file-truename'. > > Good question. > We don't really have a good answer yet, AFAIK, in large part because we > don't have enough experience with it. > Off the top of my head, here are some elements relevant to this > discussion, in random order: > > - The current setup is a kind of "minimal" change for Emacs-30 because > it's late in the pretest, so as much as possible we should separate > the discussion into what's a simple enough solution for Emacs-30 and > what we should use in the longer term. Agree. As I suggested a simple trusted-buffer-function hook may be the simplest solution, which is also not limiting and allows us to mark various buffers as trusted. > - You should be able to get fully-featured Flymake in *scratch* > with (setq-local trusted-files :all). > Maybe we should do that when we setup *scratch*? > Which other non-file buffers would need that? The minibuffer? Given that the trust applies to the given buffer, setting `(setq-local trusted-files :all)' in this buffer feels odd as a recommended mechanism. Even more so since the variable is marked as risky local. > - Trust sucks, so we really should work on better solutions where we > don't need to rely on trust, such as running code in `bwrap` or other > kinds of sandboxes. I agree. But what about interactive scenarios like auto completion? There we may be limited to trust, even if we want sandboxing in other scenarios. I think trust checking might be helpful in all scenarios where there is a "low threshold" to invoking code execution or even unintentionally. > - I think we do want some kind of hook, with which we can have (for > instance) `emacs-lisp-mode` tell Emacs to trust the user init file, > the early-init file, the custom-file, and all the files in > `load-path`. You suggest a hook which is executed per buffer? This seems similar to my proposal of a trusted-buffer-function hook. Daniel