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 10:29:41 +0100 Message-ID: <87v7vk562i.fsf@daniel-mendler.de> References: <87ed29ixu8.fsf@daniel-mendler.de> <87msgw94fz.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="26396"; 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 10:33:27 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 1tN7Tj-0006dY-FF for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Dec 2024 10:33:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tN7TO-0006i5-AN; Mon, 16 Dec 2024 04:33:06 -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 1tN7TL-0006gP-B9 for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 04:33: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 1tN7TL-0002tX-1L for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 04:33: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=1a1gJA1EN8Tp/aPr2dK7Mq8BBtvc3AwOIpDbfsCCh6Q=; b=CaWO5aH5MsHsmmNmSeMAUWHMFCeWvg69aU2d4tWsm76la66Z9dHPlxJ5FEOBLmxtOocrmUNq6nL2b3bMz/w7M1nc21rtMC/rhWZHDIp0iwl8bdyMnCSyl8qdErTsqEpyVX/OfgzSsnd4rfIjPaTv9zNR8QgqOwOLaasZF7k35Ypv2CzldG2LavYcRf1ZI/0YcAVBsiXCsulx7DXp8Uy/9elbh00+cT/PTQSY2zz3q5SgGKe80DYwPG8ojJC2zG75XaxyR1ZATlvAMS7j+zZ5gRYnrihUbyurmekYdOODi+3k25rJlN9f80xGaBhniUHyzgfvxgcniqX1D+XMBnF5PQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tN7TK-0005vM-BE for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 04:33: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 09:33: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.173434152322655 (code B ref 74879); Mon, 16 Dec 2024 09:33:02 +0000 Original-Received: (at 74879) by debbugs.gnu.org; 16 Dec 2024 09:32:03 +0000 Original-Received: from localhost ([127.0.0.1]:53521 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tN7SN-0005tK-3I for submit@debbugs.gnu.org; Mon, 16 Dec 2024 04:32:03 -0500 Original-Received: from server.qxqx.de ([49.12.34.165]:40669 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tN7SJ-0005se-LF for 74879@debbugs.gnu.org; Mon, 16 Dec 2024 04:32:01 -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=1a1gJA1EN8Tp/aPr2dK7Mq8BBtvc3AwOIpDbfsCCh6Q=; b=dfFM8jI36djwj6horUkobqTQVJ jnvLsSh9UtLl0FcByTRvGQT3rEimndufZWcPfD70fPzKg4KUTkQdoxf2tcYHIuu9KPF7AJKrnmgBG HTSIgJBctpUGwokmbdk2PjdSoBSxEv+tQwBk4b+xvqd4+k+KsCxlvMfha8whlNbfGuRI=; In-Reply-To: (Stefan Monnier's message of "Sun, 15 Dec 2024 17:41:59 -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:297160 Archived-At: Stefan Monnier writes: >> Given that the trust applies to the given buffer, setting `(setq-local >> trusted-files :all)' in this buffer feels odd as >> a recommended mechanism. > > 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. >>> - 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? > > I don't understand the question. I mean that not all of the scenarios can be run in some sandbox. If we cannot put all Capfs in a sandbox we could at least prevent auto completion entirely based on trust. >> I think trust checking might be helpful in all scenarios where there >> is a "low threshold" to invoking code execution or >> even unintentionally. > > Oh, you mean for code completion we don't want to incur the cost of > spawning a subprocess? Indeed that can be a reason to fallback to trust. The thought was rather that auto completion may be dangerous in general and since it is triggered with a low threshold one could prevent auto completion right away. I think you have a more fine-grained model in mind where certain macros are trusted and so on. > But note that in the "other kinds of sandboxes" I include things like > labeling macros with some indication about how they can be run safely, > so we can have a version of `elisp--safe-macroexpand-all` which does > something useful even if the buffer's content is not trusted. > >>> - 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. > > Yes, that's exactly what I was referring to. > At first I was thinking of some kind of `trusted-buffer-functions` hook > used with `run-hook-with-args-until-success`, but I think you're right > that it's better to go with `trusted-buffer-function` so we can both add > and remove trust with it. My initial proposal was about a global `trusted-buffer-functions' hook but I may have not communicated this clearly enough. I have two problems with the buffer-local approach: 1. I find it difficult to check what we are trusting, since the trust settings are scattered over multiple files. 2. How can I configure certain buffers to be trusted? One could configure `trusted-content' at the time of buffer creation. Or is there a hook which you suggest to use? Right now it seems that the idea is to set `trusted-content` based on major modes? Daniel