From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#75017: 31.0.50; Untrusted user lisp files Date: Mon, 23 Dec 2024 14:10:30 +0000 Message-ID: References: <87bjx43gp7.fsf@pub.pink> <86h66w6yam.fsf@gnu.org> <86ikrb5zms.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32065"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acorallo@gnu.org, jm@pub.pink, monnier@iro.umontreal.ca, 75017@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 23 15:12:29 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 1tPjAb-0008As-8a for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 23 Dec 2024 15:12:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tPjAD-0004rp-5h; Mon, 23 Dec 2024 09:12: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 1tPjAB-0004qE-2L for bug-gnu-emacs@gnu.org; Mon, 23 Dec 2024 09:12: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 1tPjAA-00052g-PK for bug-gnu-emacs@gnu.org; Mon, 23 Dec 2024 09:12:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:MIME-Version:References:In-Reply-To:From:To:Subject; bh=pU7p3fCC+J7Pbsn79VsRYethMVGfgn0yUTWngK/UtS0=; b=Dz6+itshrmSLZqlIKw6ldsqia/ze4fAWuiBIDKGfZdRKq9WA+De2HJAopODk+9i78sNv+9M/L9l1Cd1tUebom+6IC8uMBu9NtNEAlDonnslEUHluD+FxmYdilyoiYJ6KJ7QiWwdH71uSsRAqfylQpHvWvp2uOXkY8dQTnsMkcOKp436AHCnII3mD4i2NciHCA1r/+raaI4+vXbtMuBXzeEAm5Y3B6Blk5PCM95+gTlGdOoqL58pEZdB4iJJmZfm48Q3cUsdFm6Pe1ka10qZXlRyVdjndHifQZBuaSQWn7C6BMaKoAfch+58jQmGugkuoPYDTguOHPHXEDu+acRxWOg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tPjAA-0007SP-Bo for bug-gnu-emacs@gnu.org; Mon, 23 Dec 2024 09:12:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 23 Dec 2024 14:12: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.173496309728623 (code B ref 75017); Mon, 23 Dec 2024 14:12:02 +0000 Original-Received: (at 75017) by debbugs.gnu.org; 23 Dec 2024 14:11:37 +0000 Original-Received: from localhost ([127.0.0.1]:53800 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tPj9k-0007RZ-FE for submit@debbugs.gnu.org; Mon, 23 Dec 2024 09:11:36 -0500 Original-Received: from mail-ed1-f50.google.com ([209.85.208.50]:46116) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tPj9g-0007RO-0Q for 75017@debbugs.gnu.org; Mon, 23 Dec 2024 09:11:34 -0500 Original-Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-5ceb03aadb1so5843797a12.0 for <75017@debbugs.gnu.org>; Mon, 23 Dec 2024 06:11:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734963031; x=1735567831; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=pU7p3fCC+J7Pbsn79VsRYethMVGfgn0yUTWngK/UtS0=; b=PnUHRHqzFvpnDG0OmyiKGH7vJ4xM/ukmMPGtPIkepZQDV8gMfFc6rneK5H4ycp5cVp 09VESx/bsfi24QDKN2+RRXtepAXnBf7bjGeMzb1fJ+W8R1wJQBet3qa+XOiz2lYQ3WVF 2euT8zii2VMS4I6/EBFhmVBvD6kyeW5900fDfGOtRYoKXkAcj+UpYHKatMx/MJuvjfJU p6kAsEGVjaQYfbrSduOhNOExTIzIp4xUBYIgHEAv4zZQHlUOyB5iW3qUusHkB2U897Rx QhO4iinNqZthEpCRMYHgg1Y+vqPRAqGZ+NGpLl19+Ae885ItEXDkagZI0NCJs6GJFHHf UUgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734963031; x=1735567831; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pU7p3fCC+J7Pbsn79VsRYethMVGfgn0yUTWngK/UtS0=; b=udyiTo3LQTaRwdyF8VuRl1Ir2VPQB4IlUud0nwFj5+53XAxSZARDlBWMzP+xKo9SI/ VUN43IhBceOgARSJ+Q9FnhmYP2C2S082f/enQnVyhNjERCphj1lh6G3l0Pb+tXOo75sH 1ZWSpwd/yId4ptPHeA/4KttfqDlRbVSON+j029xO8jG8FI1X2emOAVYsri1xc46TendB 3cLVNHSOifH1UeokFshVLZunPpjaBqEBTyeE0Lm1W3hvyglwlOETBnn1SepNY/lOK0xe 0SEUfz+94Gna5yhSUfeH6oqwuzl43Bt25JxKOtH4dsOe8Wp3h04eXMYvczUYcH9HF+5S gXbg== X-Forwarded-Encrypted: i=1; AJvYcCUgVxGZcfIrkxLndKBeeNw70MfCxd7b8HaYaHmYYCtpCF3yurmDnlFJmOJI1gr91vcdsy5Ggg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyLKL5JtMUQKQAKIMoJ47+EYL8+iTUaiziuPVx2T7H4ylkTuhFf DxBhfYDnoVaBsFoluY4axfpzXzDc+OodpBxrOkfI9LE+UcOGP7sW+bpaxKUC2MenRezeyANiaGk an7kBJhGK/Jj9aGC9M+j22rNHntg= X-Gm-Gg: ASbGncvIxaJvIoyA6mEymRIaS0cPIGVCxKapXfzf6y/5se12GyAE3eTW9RJgwcGQFSb hZKve02W4WA3JEVWBjYnlAbwRrSEMzQfKmFP55m4= X-Google-Smtp-Source: AGHT+IF/0ycYOudodtK3nG0tBRwHry2qShWa+WWU2LcMryQm4OZogqwQMb4BwEjDX+xLWZvJOhf1NLNm4ZaC/1o5wuc= X-Received: by 2002:a05:6402:270d:b0:5d0:c684:bae5 with SMTP id 4fb4d7f45d1cf-5d81dd8fe3fmr9615559a12.13.1734963030714; Mon, 23 Dec 2024 06:10:30 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 23 Dec 2024 14:10:30 +0000 In-Reply-To: <86ikrb5zms.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:297644 Archived-At: Eli Zaretskii writes: >> From: Stefan Kangas >> Date: Sun, 22 Dec 2024 17:36:15 +0000 >> Cc: jm@pub.pink, 75017@debbugs.gnu.org, acorallo@gnu.org >> >> Eli Zaretskii writes: >> >> >> From: Stefan Monnier >> >> Cc: john muhl , 75017@debbugs.gnu.org, Eli Zaretskii >> >> , Andrea Corallo >> >> Date: Sat, 21 Dec 2024 22:16:05 -0500 >> >> >> >> > Maybe we should install something like the below? >> >> >> >> Fine by me, but I think this should be added via a new >> >> `trusted-content-function(s)` and added buffer-locally only in >> >> elisp-mode buffers. >> > >> > Sorry, but this is slippery slope. For starters, no one said that >> > site-run-file is installed by a sysadmin -- that is only so on certain >> > systems. For example, MS-Windows is generally not in that category. >> >> It doesn't matter who can edit it. `site-run-file` is already trusted, >> since it is loaded at run-time before `user-init-file`. > > It is loaded if it is there. On my system, there's no such file, and > I don't expect to have it. This seems orthogonal to the issue at hand. If you don't want to load `site-run-file`, you should use the --no-site-file flag. (We should probably take that flag into account when saying if that file is `trusted-content-p` though.) Without that flag, we load files in these well-known locations unconditionally. In my view, it then makes little sense to worry about loading any `eval-when-compile` forms (or similar) in these files when byte-compiling them. If they contain malicious code, that code has already been run when Emacs started, or it will be run the next time Emacs starts (e.g., if it has been modified after Emacs started). In other words, this case is quite analogous to `user-init-file`. > So if such a file somehow materializes there, I want to know, pronto. First, I note that it's likely already game over if an attacker can write to `site-init-file`, because they can then just as easily write to your init file (or other relevant files in `load-path`) instead. But to do what you suggest, we would need to start with deciding under what circumstances it is not expected to find a file in this location, and then not just warn but refuse to load it if it meets that criteria. I don't know how to design such criteria. If we can figure out a way to do that, then I agree that it would be consistent not to treat this file as `trusted-content-p`, when it exists unexpectedly.