From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii 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 15:38:42 +0200 Message-ID: <86wmg1qd5p.fsf@gnu.org> 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> <87cyht9kke.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28167"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mail@daniel-mendler.de, 74879@debbugs.gnu.org, monnier@iro.umontreal.ca, stefankangas@gmail.com To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 15 14:40:18 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 1tMor4-0007Aj-4e for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 15 Dec 2024 14:40:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tMoqt-0001IG-3D; Sun, 15 Dec 2024 08:40:07 -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 1tMoqo-0001FH-SZ for bug-gnu-emacs@gnu.org; Sun, 15 Dec 2024 08:40: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 1tMoqo-0007a2-JH for bug-gnu-emacs@gnu.org; Sun, 15 Dec 2024 08:40:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=BmdIsAFPobzDcPywgvKBpy66Xln+jWpKW45Xv9HLemw=; b=MGCWk4RlSmHlc2sHES42a9Wz7+FPlycbPzSxDuCv+yR7BYNqm+LxLAVzvdjEe01iZT+3SyG+S9MBStvbmn0rfn4hp/9PE7S8rtAbmuLPnFst8NafDU5NeGVvXg/qlDkRmC8hjFWYXlj/pLCJYVXBPhiJIDKieKmgo8yTsMTQGBpsy18sy27Nmxo5E4rdr0BXoA+M6D2F5FRcM8OwInTjnfqvF8Q0pVXvbr3ulNocRa2z4tH1v9ujUJHqNjAx2HseoH2aCst3FrS3ew+0i/r0qH9VMETRjHW7Kd5sXZ0249FMUM+xcF5aV/zQX3SHZinmxD1VDVJWq6qF2EAeRoOesA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tMoqn-0006CW-NX for bug-gnu-emacs@gnu.org; Sun, 15 Dec 2024 08:40:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Dec 2024 13:40: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.173426996123765 (code B ref 74879); Sun, 15 Dec 2024 13:40:01 +0000 Original-Received: (at 74879) by debbugs.gnu.org; 15 Dec 2024 13:39:21 +0000 Original-Received: from localhost ([127.0.0.1]:49951 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tMoq8-0006BE-SJ for submit@debbugs.gnu.org; Sun, 15 Dec 2024 08:39:21 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:56890) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tMoq1-0006Ar-NB for 74879@debbugs.gnu.org; Sun, 15 Dec 2024 08:39:19 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tMopv-00079X-B1; Sun, 15 Dec 2024 08:39:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=BmdIsAFPobzDcPywgvKBpy66Xln+jWpKW45Xv9HLemw=; b=cf9d3CTfoV+Q bfGBmuIPQPTQL2MqWmoKDrWAg6WqD3k145c+GkS3m97yVVLxZxzEO5TEGtiUKi15ZY8R+GBi4n9Me XyykSSoFx0BW9NHTt/6YnVStY3uSP/3GpEkrclPPSqKb5atbLmrumS0TU4aPnYogwg+6xUldqNaWu GaE91fNeHU4A7/SoommVxo7Wgfe5nGj+6hzR9onPbjErYR+4dgjni7/I7kXqMvjHC/Tq12mctN5no AzvpJ7KY63IQ49KmPRvxvj7FcT1cJnql5FD+mvm/jy9JZmg0rcdaLZiALN9gG8fT9qny1E5utOgT4 5IPvSB98cq127z6LjJj5/g==; In-Reply-To: <87cyht9kke.fsf@localhost> (message from Ihor Radchenko on Sun, 15 Dec 2024 12:50:41 +0000) 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:297102 Archived-At: > From: Ihor Radchenko > Cc: mail@daniel-mendler.de, 74879@debbugs.gnu.org, monnier@iro.umontreal.ca, > stefankangas@gmail.com > Date: Sun, 15 Dec 2024 12:50:41 +0000 > > Eli Zaretskii writes: > > > 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. "Arbitrary ELisp code" doesn't have to be malicious, just too trusting. > > 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. How can that work in practice? What can that code do to know whether the stuff can or cannot be trusted? > > 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. Now we are getting somewhere. My point is that we should probably not leave this open to some function, but instead code our own ways of deciding whether a given buffer is 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. My problem is not how NOT to trust, my problem is in which cases to trust. Saying that by default such buffers are not trusted is easy -- we already do that, in fact.