From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko 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 12:50:41 +0000 Message-ID: <87cyht9kke.fsf@localhost> References: <87ed29ixu8.fsf@daniel-mendler.de> <875xnlfdzi.fsf@daniel-mendler.de> <86cyhtrzmo.fsf@gnu.org> <87jzc1dxk2.fsf@daniel-mendler.de> <868qshry7w.fsf@gnu.org> <87y10hb2im.fsf@localhost> <8634iprux9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13477"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mail@daniel-mendler.de, 74879@debbugs.gnu.org, monnier@iro.umontreal.ca, stefankangas@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 15 13:50:38 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 1tMo50-0003Js-Jp for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 15 Dec 2024 13:50:38 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tMo4a-0002ro-Cn; Sun, 15 Dec 2024 07:50:12 -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 1tMo4T-0002rW-Uq for bug-gnu-emacs@gnu.org; Sun, 15 Dec 2024 07:50:07 -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 1tMo4S-00054E-JM for bug-gnu-emacs@gnu.org; Sun, 15 Dec 2024 07:50:05 -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=m8L9aK6htSS6dIqD2VR9A24oWoJj30pShtFdCeHnfNA=; b=hYNpbUtpltxVGqeC6j2jlVU7bn+/mIoik3UVAUxqtJ/ptjT89ElFtTUj5rkLbVAEIPYALwB0UdZJacg2VhTU3qwao8ttrCTl6fi6Y2UwICa4aj/JVw6mMCV7HEDxadj7Hnbbsu8iqrWGi2FjUmHRVV1ZaaG52XW6TXbjlw18cTbuljFfhAwV+1uw4MA36mHJWjNblRUY0mIbTpaFtWFA2R7KTQKWGCam6tKvbLsfCZXsFlqNpcZhJjGjd1NKx5w9+1KhDfw/YvtHbqpFBYQfztKoOXgM2GyAGXny51sCdVDPVWt4wfagB4jKqKF8xBjeCsEnmqIV5Fencx9Ql6R+JA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tMo4Q-0003lh-IW for bug-gnu-emacs@gnu.org; Sun, 15 Dec 2024 07:50:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Dec 2024 12:50: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.173426697114437 (code B ref 74879); Sun, 15 Dec 2024 12:50:02 +0000 Original-Received: (at 74879) by debbugs.gnu.org; 15 Dec 2024 12:49:31 +0000 Original-Received: from localhost ([127.0.0.1]:49848 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tMo3u-0003km-KS for submit@debbugs.gnu.org; Sun, 15 Dec 2024 07:49:31 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]:54967) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tMo3n-0003kK-1z for 74879@debbugs.gnu.org; Sun, 15 Dec 2024 07:49:27 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 6D83E240027 for <74879@debbugs.gnu.org>; Sun, 15 Dec 2024 13:49:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1734266955; bh=JyGM3FIGv3lOSO0a+22r9mDSrNB7Es5ZIFGuEQi0oac=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=HMRQpn5vmJY7508QUiI7BYk998/AzxXtX6R6aU0Zcot60K504TVAYoBF3h3KUwJYw msw8kDwmeWhVm15aVsr8OhhHKXItaLrFokM2LXisyaX65oEDOjOR72VaFWl6NRe88r V0iu4uh2bPwRIsUalxtm9YjOdVwGO7nZTyHnx58AEZNjm04pap60RVi1fCDxfxZobE dIO1Lf+1dIhvfDJGadrqxiSKfStYTduu2MaYALKHyKSc1SJoI542SmVL4zIRmvYDWJ aaJXoyWsW1QOkBAPBaxBWFOemI0CTPx4s+tbXTspBaMtuqvpMooIEpZ9ApM1efmYdC uaNequPKWjR/w== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YB2vZ1pSBz6ty6; Sun, 15 Dec 2024 13:49:12 +0100 (CET) In-Reply-To: <8634iprux9.fsf@gnu.org> 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:297099 Archived-At: Eli Zaretskii writes: >> If buffer contents is not coming from a file, it must be generated by >> some Elisp code. That code may as well set trust status. >> For example, *scratch* buffer may have its contents (automatically >> generated) marked as trusted by default. >> >> Does it make sense? > > Are you in effect saying that every buffer that doesn't visit a file > should be trusted? No. The code generating non-file buffers may indicate whether buffer should be trusted or not. > ... If that's accepted, it doesn't need any function. > And can we really trust arbitrary ELisp code that to set trust? When an arbitrary Elisp code is already running, there is nothing that can prevent that code from doing anything at all, including, for example, re-defining `trusted-content-p'. So, discussing whether we can trust a running Elisp code or not makes no sense in my book. We have to trust it. > And what about buffers whose contents came from a network connection? The code that is putting text received from network connection should be responsible for marking the buffer appropriately. > What about buffers whose contents came from inserting some file or > part thereof, or were generated by processing some file? Again, the code should be responsible to check things, maybe using some kind of API function to check whether a given source file should be trusted or not. > What about buffers whose contents came from a program Emacs invoked? Same thing. I'd say that the codes receiving text contents from network or from a program should not mark it as trusted. One alternative might be storing "trust flag" as text property for Emacs primitives that read file contents, network stream, or program output. Then, if any part of buffer has "trust flag" set to be not trusted, the whole buffer should not be considered trusted. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at