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#75017: 31.0.50; Untrusted user lisp files Date: Wed, 25 Dec 2024 01:29:36 +0200 Message-ID: <4ff33026-e509-41d0-8d02-e67db644a797@gutov.dev> References: <87bjx43gp7.fsf@pub.pink> <86frmg6xzf.fsf@gnu.org> <86ldw75zrd.fsf@gnu.org> <9a4969f4-858e-4493-a69f-8ca9b2861917@gutov.dev> <868qs75uwp.fsf@gnu.org> <36eb8d61-cf0c-4ac9-a679-252a46a874ee@gutov.dev> <865xna60oj.fsf@gnu.org> 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="40654"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: jm@pub.pink, stefankangas@gmail.com, 75017@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Dec 25 00:30: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 1tQEM6-000AQa-EJ for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 25 Dec 2024 00:30:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQELk-0006jE-1A; Tue, 24 Dec 2024 18:30:04 -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 1tQELj-0006j1-0y for bug-gnu-emacs@gnu.org; Tue, 24 Dec 2024 18:30: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 1tQELi-0006UI-O4 for bug-gnu-emacs@gnu.org; Tue, 24 Dec 2024 18:30:02 -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=RE8kaIHS/N50Naf25uEaOZ0FRe+zAvG/dCtvwhvizp4=; b=YaAgWN8ERZjnz7SqUe01X7SgoIfdk7y+8Yt9sTY0FInN3c+dchmqOAyLwNJ+o5JTm0X3hgAKSbJUEIllZZ2+HG6FoXnEPD0aqjNbhHQPLnjpNVT6s5YymWICN2Kh2iIOliE9bHF4B6afLCBBjJULmBOnWJJ/FDzpn0Yh9ZGbaCOoFGbxAa3tK4Ph9Tp+ci8qLl95mOS7gdPJ8E53unPUoz/ZurB35LgkbuO/ZvAGTiI6JioxFYWE8ye8mH0xg7hxf3/n88h7lVcVSA3dwZ6nEJVLRQQDqlS01N+Q5w83m3jJ+CwrhW1V6qU+dsT+iadz5IbPI2Uz1S92EZ6/J7g49w==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tQELi-0005o2-H3 for bug-gnu-emacs@gnu.org; Tue, 24 Dec 2024 18:30: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, 24 Dec 2024 23:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75017 X-GNU-PR-Package: emacs Original-Received: via spool by 75017-submit@debbugs.gnu.org id=B75017.173508298722266 (code B ref 75017); Tue, 24 Dec 2024 23:30:02 +0000 Original-Received: (at 75017) by debbugs.gnu.org; 24 Dec 2024 23:29:47 +0000 Original-Received: from localhost ([127.0.0.1]:35369 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tQELT-0005n4-3M for submit@debbugs.gnu.org; Tue, 24 Dec 2024 18:29:47 -0500 Original-Received: from fhigh-a8-smtp.messagingengine.com ([103.168.172.159]:46669) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tQELR-0005ms-Sd for 75017@debbugs.gnu.org; Tue, 24 Dec 2024 18:29:46 -0500 Original-Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfhigh.phl.internal (Postfix) with ESMTP id C521B11400F8; Tue, 24 Dec 2024 18:29:40 -0500 (EST) Original-Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-11.internal (MEProxy); Tue, 24 Dec 2024 18:29:40 -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=1735082980; x=1735169380; bh=RE8kaIHS/N50Naf25uEaOZ0FRe+zAvG/dCtvwhvizp4=; b= B2u00Vn8NFKX6x/GsiQ39492Zwyybkyl3b2eCo7HLGNaFs7vziaszZl4wXG3mVXp AgdFWq7BTTRGgtnGhaDRqtRKZdwVdhoGreXCuZleiaPcbLg1eYsr8evJCMMtoc+I aEGZ9EuaEvooAEq/+fFopco3UdmrIMYg4ZE3nzIMHoVsy/xeUQnJyOjOT0BMk5Od Ou3SKoDYrRcXfrDD+Gj+yH/djyeGt+apGEnsyKKR2Tp+Fy4o93tc2kGRu1nOM8/o n3pjbXoBANZQ0jFAO2mM2HRqlnK0IynRdepPA7immGjbjr43QgIw563/U7EZu9cS iE71AN1XtvHRkGm8B1AIAw== 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=fm2; t=1735082980; x= 1735169380; bh=RE8kaIHS/N50Naf25uEaOZ0FRe+zAvG/dCtvwhvizp4=; b=V ybZ3CRuBLZS48eL+qXvErtvnTNGfG2RAvNuO2jEulMDRNP06jkJl2GRzuxF9OMDT WaIxCQvKDQ6u0MCSh6SvcjYkNeq2QBS8hdGMNSdslC18vN5EtqYUUHxTfjIwoXXc 5rc/OOahdkktFhkVjX6yjDvtUVIYLtda5cZpoStEQprrDeer/wEB/eCXAETxDGYw y+5OvARYgPb9rev0dFqVF81GqSXhc00T6a5mHDD/In2bEtQGd1c4qkWHULAyAdks jJxnJgDDuSnh1UBGewXPLcKsAVQk27+Z1a/34d0gUFEA8ohRLpRr/2wXQxShD6zs Jj6U04Mg3lNeJMUU1lP6g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudduhedguddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdej necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdrug gvvheqnecuggftrfgrthhtvghrnhepteduleejgeehtefgheegjeekueehvdevieekueef tddvtdevfefhvdevgedujeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthho peegpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrgh dprhgtphhtthhopehsthgvfhgrnhhkrghnghgrshesghhmrghilhdrtghomhdprhgtphht thhopehjmhesphhusgdrphhinhhkpdhrtghpthhtohepjeehtddujeesuggvsggsuhhgsh drghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 24 Dec 2024 18:29:38 -0500 (EST) Content-Language: en-US In-Reply-To: <865xna60oj.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:297707 Archived-At: On 23/12/2024 14:31, Eli Zaretskii wrote: >>>> And Emacs will load whatever's written there on the next restart. >>>> Whether the user wrote to those files, or someone else. >>> Yes, and your point is..? >> That whatever malicious code we try to protect against using the >> "trusted content" mechanism would be executed anyway. > The scenario I have in mind is this: > > . Emacs session is running; when it was started, there was no > site-init file > . User notices that site-init file appeared > . User visits the site-init file > . Malicious macro in site-init file is executed > > IOW, there could be valid situations where the user visits the file > before restarting Emacs (which would load the file). In these > situations, it would make sense to treat the file as not trusted -- > unless the user tells us it should always be unconditionally trusted. > > IMO, we should only make files and directories trusted by default if > we are either 100% sure they can never be malicious Thank you. So the scenario where we would make the distinction is when the user managed to notice (somehow?) that the file had changed during the Emacs session, and then went to edit it. To be frank, I asked the question after reading the scenario from the first message, and it talks about early-init-file. IIUC this file lives in the same dir as the plain user-init-file, so the chances of them being edited by someone other than the user should be about equal, and we do "trust" the latter file automatically. Probably not too critical, but inconsistencies can be annoying (the user has to spend time figuring out whether something is broken and why).