From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers Date: Tue, 17 Dec 2024 03:42:16 +0200 Message-ID: References: <87ed29ixu8.fsf@daniel-mendler.de> <875xnlfdzi.fsf@daniel-mendler.de> <643a50f9-2128-405b-ae5b-114990b3dfc2@gutov.dev> <87h6739245.fsf@daniel-mendler.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31429"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 74879@debbugs.gnu.org, Stefan Monnier , Stefan Kangas To: Daniel Mendler Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 17 02:43:19 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 1tNMcI-00082f-Lo for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 17 Dec 2024 02:43:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tNMc7-0006fq-Ug; Mon, 16 Dec 2024 20:43:08 -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 1tNMc3-0006fa-Rk for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 20:43:04 -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 1tNMc2-00027P-T6 for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 20:43:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=In-Reply-To:From:References:MIME-Version:Date:To:Subject; bh=sKfssRgyKLLSPSV6jyWXiCrF2s7FNoU4DUUyzqKvWAQ=; b=eXTtKe87u2EYx/tco62Z9psDRfgxlNlaR/AgS7SBxR1BrxONX8U0XHzF5hDgxMYVRZPZnVudHQvAAY6l+Az6GrOcX+NNBJ14B+becdqKVvI8KLbkNDxfdZEYL2eWPSOrQynsji8Ti9Ce2y9M5NYejLVyr3P47GQKP9qOsKGOwGEit/YdPMqPaMGS5M+iEMVC5Thvds1He9WjsqPjtDrkCbHoKoDUzGhwCDlLbY3BDqlPGybWzBm721eIa+7m7qraeRX0Ye/RtOV86KTrp20uL+kyFa301MCu6LyaIip6TlbDrFEOkrBmVrr0zBLJMTNOMznaGNSvLeHcqP87oonJag==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tNMc2-0007Lz-9P for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 20:43:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 17 Dec 2024 01:43: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.173439975028213 (code B ref 74879); Tue, 17 Dec 2024 01:43:02 +0000 Original-Received: (at 74879) by debbugs.gnu.org; 17 Dec 2024 01:42:30 +0000 Original-Received: from localhost ([127.0.0.1]:56879 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tNMbV-0007Kz-UQ for submit@debbugs.gnu.org; Mon, 16 Dec 2024 20:42:30 -0500 Original-Received: from fout-a8-smtp.messagingengine.com ([103.168.172.151]:40861) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tNMbR-0007Kc-VS for 74879@debbugs.gnu.org; Mon, 16 Dec 2024 20:42:27 -0500 Original-Received: from phl-compute-04.internal (phl-compute-04.phl.internal [10.202.2.44]) by mailfout.phl.internal (Postfix) with ESMTP id 57A571380167; Mon, 16 Dec 2024 20:42:20 -0500 (EST) Original-Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Mon, 16 Dec 2024 20:42:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1734399740; x=1734486140; bh=sKfssRgyKLLSPSV6jyWXiCrF2s7FNoU4DUUyzqKvWAQ=; b= NLShYyIcBJzsT5PhL+wc74/b+PdcAWcf0p5kaO5OlESkxNTXG+3MEsT/WPR9tgbR bkFp/vpy5bQsyFtCyDUoHpKYOZMVm2q4ougOuhSLbFeUsjnP0VZMFesDpuXnHbSu UaymqYXO1WPUH8TdgWmpDfD5Q1p+gxlT7jtkGsIJq+Qzm6Gm6d+GF1oEq2zUoyUg qerI3kbgEIYblrYY18KHaTxRuDT0pC3R2XYZh2uYd8rakQlk93lcxdsXlYUZU1Ml OUgtdGIiOJea9ZPWbJDu+gKaY3qEl1MY15w02ybGDuB2WlU+2ozKg2WDBF1fw4/S SrXIJ2v98vYSDtqrphRwFw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1734399740; x= 1734486140; bh=sKfssRgyKLLSPSV6jyWXiCrF2s7FNoU4DUUyzqKvWAQ=; b=Q 8BhDBCdz60gMGvVifMtA+PevIL7e7Uqa9jgn/zDjdfmLc6pCTl1X1GeS7NTMSi5u ilwuZyHy+LyPJ8sJR3wM/BkbQmK+xQeOyHaDc/xvBlMee3vR+SilmZkzUrp1emrz JmntiegYjMCMLbyVwaCdMNI0inm9w1EKnjkBwIx/PlgMa04r3LlO8JZZNZ/2A5JC RjFIDPfOkjHv8/gchYZOXz9fhSgGaY0LKgqS+aSuKOQ3Pl+CXL0D5cW6GJ8uiPB8 Ivf1sZpr+M6oKVYUSFK9uCghb79i9yPP02VkDVp8hhAQE+owSIZv+5lmmfNPnuJv vwoXig9PvsJOUiUX0orVA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrleeggdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeen ucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvg hvqeenucggtffrrghtthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedt vddtveefhfdvveegudejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohep gedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepmhgrihhlsegurghnihgvlhdqmh gvnhgulhgvrhdruggvpdhrtghpthhtohepjeegkeejleesuggvsggsuhhgshdrghhnuhdr ohhrghdprhgtphhtthhopehmohhnnhhivghrsehirhhordhumhhonhhtrhgvrghlrdgtrg dprhgtphhtthhopehsthgvfhgrnhhkrghnghgrshesghhmrghilhdrtghomh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 16 Dec 2024 20:42:18 -0500 (EST) Content-Language: en-US In-Reply-To: <87h6739245.fsf@daniel-mendler.de> 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:297243 Archived-At: On 16/12/2024 15:41, Daniel Mendler wrote: > Dmitry Gutov writes: > >> On 15/12/2024 12:16, Daniel Mendler via Bug reports for GNU Emacs, the Swiss >> army knife of text editors wrote: >>> For example in my GNU ELPA Corfu package the plan was to check >>> `(trusted-content-p)' when starting auto completion. >> >> Shouldn't that be done in the c-a-p-f function? > > Yes, this is a more fine-grained approach. Stefan added a check to the > macroexpansion in Emacs 30 which should make the Elisp Capf safe. > > But consider other scenarios like Org-babel or Embark. Org-babel can > execute code blocks and Embark can evaluate Sexps at point. For these > cases it makes sense to check if the buffer is safe before running the > action. However in contrast to auto completion one has to press a > special key to trigger the evaluation. Code execution, or sexp evaluation, are like the reverse of our scenario because when the user executes code, they _have to_ be aware that they execute code. And it's not like using sandboxing would be obviously correct for the "interactive notebook" case because a lot of people will want to have the code be able to read and write files, for example. This is in contrast to bytecomp warnings or code completion, neither of which has to have direct I/O access. But the latter might need to access network, or launch programs, anyway, so limiting the capability seems to fall squarely into the area of the completion function. >>> To be clear - Corfu >>> is safe by default, since auto completion is disabled by default. >>> However many people enable auto completion unconditionally in all >>> buffers. >> >> Having completion invoked manually doesn't really ensure that the user knows >> about the odds of it running code from the current file. Some languages do that, >> some don't, and the newbie Lisp users have little idea of what macro expansion >> in completion entails. > > That's correct. Nevertheless Eshel specifically mentioned auto > completion in his report. I think that the threshold for auto completion > is a little lower - the user enters normal text and potentially code > execution of in-buffer code happens behind the scenes. And with code completion they press C-M-i - which is something people do regularly as well. It wouldn't really matter than auto-completion handler runs once per input while you only press C-M-i once per minute, or even once per hour. To compromise a system or the user's data (this is what we're talking about, right?), it only needs to happen once. I don't imagine we're going to slap a "there be dragons" warning on every auto-completion option, and on 'completion-at-point' either.