Received: (at 74879) by debbugs.gnu.org; 11 Jan 2025 14:30:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 11 09:30:25 2025
Received: from localhost ([127.0.0.1]:41854 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tWcVM-0007OW-Ri
for submit <at> debbugs.gnu.org; Sat, 11 Jan 2025 09:30:25 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:53409)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1tWcVI-0007KX-QK
for 74879 <at> debbugs.gnu.org; Sat, 11 Jan 2025 09:30:21 -0500
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 789AF8001C;
Sat, 11 Jan 2025 09:30:13 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1736605808;
bh=c8P2VbsRDRTkANyeV2cfvJLnBmmPWbINbJsgCF0dYrg=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=UfvM6KqFEX49aQHmwgDa+BTTngBbvQqOAjZ8h8oV8YimSnRw0wC14jdHBBkksB51a
IndSFko7vuZdn5FkHKf5TuWTu79Ipt+kDW2OyjkP6RUGYkJHI8HF9uvXUIxLzCUNN0
Q2GxbmJ6wcZMwCuRPjcIqGogsj5A3HhX+WnG2MBfyX2OJzIhHMYdqVEy9xAiCddDg0
Ff1fgko/INkE654IGMcom9sluJnC5XcnBS0lxwLaBq3sLeyG4GpYbiA2a1GxxzsBLe
3XXCPBdpWuX/HYMixucGphmUNVsyle27igv+r0Ja1ooBEppTWwAXurCY5f5rA7Vc3p
42JZMy1k9t1BA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 17B5480152;
Sat, 11 Jan 2025 09:30:08 -0500 (EST)
Received: from pastel (104-195-232-86.cpe.teksavvy.com [104.195.232.86])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D77E81207E0;
Sat, 11 Jan 2025 09:30:07 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Stefan Kangas <stefankangas@HIDDEN>
Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot
be used for non-file buffers
In-Reply-To: <CADwFkmm1Fhuoq0UozU7iA70skQAE1113UQ1TKCiXNjRY1UTc9Q@HIDDEN>
(Stefan Kangas's message of "Sat, 11 Jan 2025 13:54:22 +0000")
Message-ID: <jwvy0zh5t6b.fsf-monnier+emacs@HIDDEN>
References: <87ed29ixu8.fsf@HIDDEN>
<jwvikrlukf7.fsf-monnier+emacs@HIDDEN>
<e41a4abc-f095-4c9f-b25f-57ecfbd39a59@HIDDEN>
<CADwFkm=gO_HZwXnMBGbwvhKL99z9nQtxShmDcgK0WmZ_5dFrBQ@HIDDEN>
<87v7ulmwyj.fsf@HIDDEN>
<CADwFkmmSr342G0Tr+x=5qjC1Mct1-h0BpC+se4f_4k+-+4YDHQ@HIDDEN>
<8734hp4j97.fsf@HIDDEN>
<CADwFkmm1Fhuoq0UozU7iA70skQAE1113UQ1TKCiXNjRY1UTc9Q@HIDDEN>
Date: Sat, 11 Jan 2025 09:30:06 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/x-markdown; charset=UTF-8
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.040 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 74879
Cc: Daniel Mendler <mail@HIDDEN>, 74879 <at> debbugs.gnu.org,
Dmitry Gutov <dmitry@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> As I argued, using bwrap for package compilation will not yield
>> additional security benefits, since this will only push the confirmation
>> slightly to the future, to the time when the package is loaded.
> "Slightly to the future" could be "never" if the package is unused.
> (Assuming that we also do something about autoloading.)
We'd need to do more than "something about autoloading": a malicious
php-mode package could come with a `python.el(c)` file.
Reducing the potential for harm from installed ELisp packages is
not a bad idea, but it's hard.
Also, while some packages like php-mode can naturally be confined to
special cases, others are harder to confine and many of those others are
written under the assumption that if you have installed it it's because
you want to use it almost always, so they make no effort to load lazily.
> While I like some of your ideas, the point that I was making is simply
> that it would be better if ELisp compilation took place in a safe
> sandbox. I don't claim that this will fix all security issues, but only
> that it will specifically fix one issue: code from packages or visited
> files would no longer run with the same privileges as Emacs when
> installing packages or with flymake.
Of course, that will tend to break those packages which use their ELisp
compilation to build their C module.
Stefan
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.
Received: (at 74879) by debbugs.gnu.org; 11 Jan 2025 13:54:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 11 08:54:33 2025
Received: from localhost ([127.0.0.1]:41799 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tWbwf-0005P5-8e
for submit <at> debbugs.gnu.org; Sat, 11 Jan 2025 08:54:33 -0500
Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]:61660)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>)
id 1tWbwc-0005Oo-JA
for 74879 <at> debbugs.gnu.org; Sat, 11 Jan 2025 08:54:31 -0500
Received: by mail-ed1-x52d.google.com with SMTP id
4fb4d7f45d1cf-5d3f28a4fccso4039896a12.2
for <74879 <at> debbugs.gnu.org>; Sat, 11 Jan 2025 05:54:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1736603664; x=1737208464; 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=oIW0s81O4tc15KQh7gCmDLdyOOkDkN78xNRrgJlC4mY=;
b=f5S1uuA2ePUs3VrpECzQqj2+YhGdGoeQacyq5urMsWPoOu/5tGkg+u9Re+yCz91RK0
UKFRlIZ5Ee2BnGUMYvcHm+LriXEMIkLXXmxELb5k8mD2IrKvBns8DJ95YzgbLY7HXcAj
3Ml1RN3+y9FaLuFVZbF+P2L3ZcmD5tJsPJ8LTBp441fJXwS78xd87qIEdsI5iHdD8k2Y
YK1DgFDVdqcPC8N3jst6r9c5f15e3NayEQqlcLuJMG9Q0ZU800Gxu7fsinpbCs/yDZeL
QMHElQPv7qebwKVpNnTixUIHMl8IO5VDPICgaP3tOoEpEXHP7HOIjF7oLi6j1+aBi3Ej
pr+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1736603664; x=1737208464;
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=oIW0s81O4tc15KQh7gCmDLdyOOkDkN78xNRrgJlC4mY=;
b=pvxnUAbbf3ew30kVoPkDYVQzjWxyjsXeuyLGTD1A7MgMH+jqIzjw5xysoyGA5uV5J2
t67BR/SE3oUrvopefJRD4kUwXBtNJiBZrxbM/1iqys/s62V+FxA8OYDUSwo9QoxDLitM
x6MWpt1XRbHcwoMOjPYtYpLi/+bonwdi8FCCDn8SRS2fkETC6WBbct5xOP6fMZwq5gyS
HEtl9BeGuT3ivjzckue2h57+TlnBfguPMkAS07br6ioZF4t+ZdLzUtCtHLIcWQQZmKDX
I+itNDGQ20kuCztivCoAlyuTuCTx4NZU8a9lwjNuxr8S0eB9X3+aeG2EPzA4609tZNNV
jZSQ==
X-Forwarded-Encrypted: i=1;
AJvYcCVa+DDMbaAjUQSACRRRE4X3KWL6dE44D8THvM69lvj/gWxu80bBDcc2YRbRiazq+WBzjpSubQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YzCfmJZLv3qoTCHSt65Kyhy6EngFrAjMT1gKFOOFvHei4tjjbWN
Iy8B//qkkn91orWwqLFrJrhe7Cobk4MKAx86ecewVXh+PgKquVU/WdIg4HQgMNM+0Rw7hhqRA3y
fIp2l3/fqE+8VHVnhK532qboZGZZFSw==
X-Gm-Gg: ASbGncsM4e35wLOF64brEjx28/BYCJ8EdJ5n+sGA7Fsy98xv5+TURcs2CGMf1T6uTGR
Ku0fCqQ5MoCdnOndvMUPFK1ewhYWNZ21Rs8qLCxT2
X-Google-Smtp-Source: AGHT+IE3gGeW0szwvVj5fvaLIaxRA5CP2oWQNLxr2fcCD4W9nBPpbTAA+ZdQwLiyaW5V2AlR763FN9zn1ajgkoe3bR0=
X-Received: by 2002:a05:6402:2746:b0:5d0:b925:a8a with SMTP id
4fb4d7f45d1cf-5d972e163c5mr12141280a12.16.1736603663414; Sat, 11 Jan 2025
05:54:23 -0800 (PST)
Received: from 753933720722 named unknown by gmailapi.google.com with
HTTPREST; Sat, 11 Jan 2025 13:54:22 +0000
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <8734hp4j97.fsf@HIDDEN>
References: <87ed29ixu8.fsf@HIDDEN>
<jwvikrlukf7.fsf-monnier+emacs@HIDDEN>
<e41a4abc-f095-4c9f-b25f-57ecfbd39a59@HIDDEN>
<CADwFkm=gO_HZwXnMBGbwvhKL99z9nQtxShmDcgK0WmZ_5dFrBQ@HIDDEN>
<87v7ulmwyj.fsf@HIDDEN>
<CADwFkmmSr342G0Tr+x=5qjC1Mct1-h0BpC+se4f_4k+-+4YDHQ@HIDDEN>
<8734hp4j97.fsf@HIDDEN>
MIME-Version: 1.0
Date: Sat, 11 Jan 2025 13:54:22 +0000
X-Gm-Features: AbW1kva18-UXR_tIWaMWgmnRjoIAt1vvBQd6jA82fyZgAoa-sjyoYDDy3qZ85m0
Message-ID: <CADwFkmm1Fhuoq0UozU7iA70skQAE1113UQ1TKCiXNjRY1UTc9Q@HIDDEN>
Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be
used for non-file buffers
To: Daniel Mendler <mail@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 74879
Cc: Dmitry Gutov <dmitry@HIDDEN>, 74879 <at> debbugs.gnu.org,
Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Daniel Mendler <mail@HIDDEN> writes:
> As I argued, using bwrap for package compilation will not yield
> additional security benefits, since this will only push the confirmation
> slightly to the future, to the time when the package is loaded.
"Slightly to the future" could be "never" if the package is unused.
(Assuming that we also do something about autoloading.)
>>> Which additional benefits do you see if ELPA packages are compiled
>>> inside bwrap? The trust will only be pushed a little to the future.
>>
>> Consider packages that are used very rarely. I'd prefer to have
>> `php-mode' installed, but I can't even remember the last time I had to
>> look at a PHP file. It could be more than 10 years ago.
>
> I see your point. Like you, I probably have not opened certain file
> types in years, but I have the modes around. So what do you envision?
While I like some of your ideas, the point that I was making is simply
that it would be better if ELisp compilation took place in a safe
sandbox. I don't claim that this will fix all security issues, but only
that it will specifically fix one issue: code from packages or visited
files would no longer run with the same privileges as Emacs when
installing packages or with flymake.
If you are not convinced that this will improve security, then that's
fine. We can agree to disagree.
Meanwhile, I think you have presented some other good ideas. Feature
requests and patches to implement those will be enthusiastically
received. Thanks in advance.
> My argument is that the `php-mode' you have installed is considered to
> be safe, since you trusted it back then. Hopefully you have checked it
> carefully back then and installed it from a source you trust.
That model doesn't work here, because I install rarely-used-mode with something
like
(use-package rarely-used-mode :ensure t)
which means that it's installed again and again on every new machine, as
well potentially also every time I say 'M-x package-upgrade-all'.
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 11 Jan 2025 12:39:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 11 07:39:46 2025 Received: from localhost ([127.0.0.1]:41707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tWamH-0001oc-Nw for submit <at> debbugs.gnu.org; Sat, 11 Jan 2025 07:39:46 -0500 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1]:40763 helo=mail.qxqx.de) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1tWamD-0001oB-Ue for 74879 <at> debbugs.gnu.org; Sat, 11 Jan 2025 07:39:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eCnFvV/qjB9IlwTe4hwTEUYz3WH+1X00hBQaF5iwp/c=; b=NXzraLh4LOUu9nwO6UdislpJRZ 2LVJ6X8uA1n+otbm+IUjogxBMRkYvqnYIzQ6Ey9EwnOZDwrnyZGzSq3R3DNzBSPPA2MRwvWsFybSq VItIsHPW+XlylfbFJ3Q7ggcEVhyeXB/E/PRL/C45hJANr+Lw5PrOBaRzzleQgc24HPwo=; From: Daniel Mendler <mail@HIDDEN> To: Stefan Kangas <stefankangas@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers In-Reply-To: <CADwFkmmSr342G0Tr+x=5qjC1Mct1-h0BpC+se4f_4k+-+4YDHQ@HIDDEN> (Stefan Kangas's message of "Sat, 11 Jan 2025 12:12:41 +0000") References: <87ed29ixu8.fsf@HIDDEN> <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> <e41a4abc-f095-4c9f-b25f-57ecfbd39a59@HIDDEN> <CADwFkm=gO_HZwXnMBGbwvhKL99z9nQtxShmDcgK0WmZ_5dFrBQ@HIDDEN> <87v7ulmwyj.fsf@HIDDEN> <CADwFkmmSr342G0Tr+x=5qjC1Mct1-h0BpC+se4f_4k+-+4YDHQ@HIDDEN> Date: Sat, 11 Jan 2025 13:39:32 +0100 Message-ID: <8734hp4j97.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74879 Cc: Dmitry Gutov <dmitry@HIDDEN>, 74879 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Stefan Kangas <stefankangas@HIDDEN> writes: >> 3. Installation of packages is confirmed via package.el and does not >> happen without user consent. > > Yes, it is "not our fault" because "you shouldn't have done that" and so > on. However, whether or not we are technically at fault, we should > still work to make Emacs safer to use, IMO. As I argued, using bwrap for package compilation will not yield additional security benefits, since this will only push the confirmation slightly to the future, to the time when the package is loaded. Confirmation should happen as early as possible and as soon as the confirmation is given, the package is trusted. When confirming, a reasonable amount of information should be shown, e.g., a diff, if the user has requested that such that they can evaluate if they indeed trust the package. I think it is not a good idea to have some packages in the elpa/ directory which are marked as trusted and some packages in the directory which are not trusted. I only want to have trusted packages there and nothing else. This means that trusting the packages has to happen before installation. >> As soon as the user agrees to install a package, they agree that the >> package will shortly become part of the `load-path', and that its code >> will be executed shortly. If we believe that package installation is not >> safe enough, additional louder confirmations and warnings could be >> added: When adding new archives (additional validation of >> `package-archives') and second and when installing or upgrading >> packages. For example `package-upgrade-all' tells me how many packages >> it wants to upgrade but not even which packages - I really want to >> inspect the list of upgradeable packages first. > > Good ideas, thanks. Feel free to submit feature requests. Thanks. I have already submitted some of them. Most of them are relatively small issues to improve. >> Which additional benefits do you see if ELPA packages are compiled >> inside bwrap? The trust will only be pushed a little to the future. > > Consider packages that are used very rarely. I'd prefer to have > `php-mode' installed, but I can't even remember the last time I had to > look at a PHP file. It could be more than 10 years ago. I see your point. Like you, I probably have not opened certain file types in years, but I have the modes around. So what do you envision? You want to confirm package loading for rarely loaded packages? You want to have an additional confirmation step for rarely loaded packages or for all packages? My argument is that the `php-mode' you have installed is considered to be safe, since you trusted it back then. Hopefully you have checked it carefully back then and installed it from a source you trust. The situation is different when upgrading the package. Then I argue that additional confirmation is needed and more information should be shown *before* the upgrade, e.g., the diff. But as soon as the upgrade is confirmed, the package should be trusted, since it may get loaded. Daniel
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 11 Jan 2025 12:12:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 11 07:12:51 2025 Received: from localhost ([127.0.0.1]:41677 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tWaMF-0000W2-4Q for submit <at> debbugs.gnu.org; Sat, 11 Jan 2025 07:12:51 -0500 Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]:53448) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1tWaMC-0000Vl-6k for 74879 <at> debbugs.gnu.org; Sat, 11 Jan 2025 07:12:48 -0500 Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-aa6c0dbce1fso395421466b.2 for <74879 <at> debbugs.gnu.org>; Sat, 11 Jan 2025 04:12:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736597562; x=1737202362; 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=XiZ2zT6N2o91qUxp1r4fBOfn3Bg7EkGTiVZesre4Wjk=; b=msBM3KUetWkkYXew7jIN0qIG2f4+w5Lumg6OLaamFuys8uLiLj/4sSxPJkLQc8eRKq JG97KplM7FrWe1VKOeBQ7x9WFp2z02Li4JyOYUZjc76uS6SxIpag6F8uZuXGLi6L2DGr Dl69Zp0dZjBVQ9xApZWSnej1278tbQGBG0vAY3ukAnVX1xzItQ40oGhRzvZC5i+Y8L1q dxEw007bspKmBgLLH/9ynvWdtGIxmr9I/SA4g01y/XM/8d8OI96PWSsZAn3V92FeyoKr C2hEgQhM1ScGrAZCi35cPkENn2/8q0XBwiBBp0R7/9kYiZow2fL7R4/BmfrK47WdoW6/ eVsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736597562; x=1737202362; 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=XiZ2zT6N2o91qUxp1r4fBOfn3Bg7EkGTiVZesre4Wjk=; b=mCaGmgj3LlB+EQpdfQQe7N7TRmH+PvGIglO5QzscpjvmSU+OQE2NHm8OodGP82pwqQ 92DqHYrwrzMkvmN8CsgSSIZS7Xu0qJI9LRrEhfbsdhE6WVMtJzh2ZHOsxo4ePmpjoH/J NMBYyJQD0qffktIEHA45H51J9ibUUks+yPj4dvvMWvvYxF4RQqZDMv5GygF1q9u6ybEN qw6E3x2uHzGJYIR3xMNb/63AI4r5XjvgJL8ixS+15Xd8JAGETgPko50UwbammMz3OyBD lKqCH6zpF2Ru6a72RQsLgSl+ut6kaVAZn+2tkX2imRCvVtgxLXWna/Wye2Htzzaws7I/ gEEg== X-Forwarded-Encrypted: i=1; AJvYcCXznTUESoUTZ1thjoxiih5fwjIC5YsfUmPpryDk8t3BRmwbfhaD6+lem3tzNTfcVP0fxFFMgw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyTj5z2nDTJbZPlQRvxvgIn4GDR8x96jl6nTXwMK/gVzYLwcRtg qK1LZV+xCwDqw+PBJ0+W1DUnruUKWoiXx++f6Vjzp08dWOSYznchRILHNjHbAc5in4/xnv2NpC/ /y1QQMe4DZ3XtWQIefQPuVMPQLZI= X-Gm-Gg: ASbGncu+Dm+rVuKQC9/aSVQoGUH4OCV9/arOWmoCcaBub2Us80OBPNrY3rRmo7h5kds Yd0qd2bGSC9ik9tVG70OuqUPPhRBQ6br7imU7ABKx X-Google-Smtp-Source: AGHT+IELppCbgLehjcmtnu3mY//OIBvXoB8VlqoijZi27NXE/UNsrz64mN8VMUao03chwm/FYqNgx1zV9aRUNbOys9E= X-Received: by 2002:a05:6402:4310:b0:5d6:48ef:c19f with SMTP id 4fb4d7f45d1cf-5d972e708a1mr31792933a12.29.1736597561505; Sat, 11 Jan 2025 04:12:41 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 11 Jan 2025 12:12:41 +0000 From: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <87v7ulmwyj.fsf@HIDDEN> References: <87ed29ixu8.fsf@HIDDEN> <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> <e41a4abc-f095-4c9f-b25f-57ecfbd39a59@HIDDEN> <CADwFkm=gO_HZwXnMBGbwvhKL99z9nQtxShmDcgK0WmZ_5dFrBQ@HIDDEN> <87v7ulmwyj.fsf@HIDDEN> MIME-Version: 1.0 Date: Sat, 11 Jan 2025 12:12:41 +0000 X-Gm-Features: AbW1kvYFjjRHFN1iU-sbIOTdgNNE6yfNsTr_QuSaUIEdTZrZlfW_FG9VuZZTtWE Message-ID: <CADwFkmmSr342G0Tr+x=5qjC1Mct1-h0BpC+se4f_4k+-+4YDHQ@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers To: Daniel Mendler <mail@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74879 Cc: Dmitry Gutov <dmitry@HIDDEN>, 74879 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Daniel Mendler <mail@HIDDEN> writes: > ELPA packages can be trusted more for multiple reasons: There is no doubt about that, indeed. > 1. They come from known sources, from curated archives. Admittedly the > archive review is not sufficient. I've suggested to add review > facilities to package.el, see bug#74604. Furthermore I've suggested to > add git commit signature checks to GNU/NonGNU ELPA, see bug#61277. These are all good ideas. > 2. There is the barrier of adding untrusted archives to the > `package-archives' list. The user has to opt-in explicitly to that. True, but in practice most people add MELPA because that's what is commonly recommended online. > 3. Installation of packages is confirmed via package.el and does not > happen without user consent. Yes, it is "not our fault" because "you shouldn't have done that" and so on. However, whether or not we are technically at fault, we should still work to make Emacs safer to use, IMO. > As soon as the user agrees to install a package, they agree that the > package will shortly become part of the `load-path', and that its code > will be executed shortly. If we believe that package installation is not > safe enough, additional louder confirmations and warnings could be > added: When adding new archives (additional validation of > `package-archives') and second and when installing or upgrading > packages. For example `package-upgrade-all' tells me how many packages > it wants to upgrade but not even which packages - I really want to > inspect the list of upgradeable packages first. Good ideas, thanks. Feel free to submit feature requests. > Which additional benefits do you see if ELPA packages are compiled > inside bwrap? The trust will only be pushed a little to the future. Consider packages that are used very rarely. I'd prefer to have `php-mode' installed, but I can't even remember the last time I had to look at a PHP file. It could be more than 10 years ago.
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 11 Jan 2025 11:06:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 11 06:06:24 2025 Received: from localhost ([127.0.0.1]:41515 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tWZJw-0005eB-7A for submit <at> debbugs.gnu.org; Sat, 11 Jan 2025 06:06:24 -0500 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1]:45973 helo=mail.qxqx.de) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1tWZJt-0005dn-9u for 74879 <at> debbugs.gnu.org; Sat, 11 Jan 2025 06:06:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=H+KZpaO7F4nqL55toE1hJorwvoh8n9NsKJC1rNywV1M=; b=INap3DRrLNPVsTsetVqNvLyOtO kkCZ7NzjbhnFqRRhqOnoIkb06wU83QLe3YAw3Q3kVoGrsTJ91oeM/qcl7U0vBzz4iM0qozAmBK7Ce iCk8ZUjMLN7rx+89jXdsq+VyVFZA5edrrXwV/ox+klZNTLdjI9c1kmKaLhffzFPFmAaY=; From: Daniel Mendler <mail@HIDDEN> To: Stefan Kangas <stefankangas@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers In-Reply-To: <CADwFkm=gO_HZwXnMBGbwvhKL99z9nQtxShmDcgK0WmZ_5dFrBQ@HIDDEN> (Stefan Kangas's message of "Sat, 11 Jan 2025 01:56:01 -0800") References: <87ed29ixu8.fsf@HIDDEN> <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> <e41a4abc-f095-4c9f-b25f-57ecfbd39a59@HIDDEN> <CADwFkm=gO_HZwXnMBGbwvhKL99z9nQtxShmDcgK0WmZ_5dFrBQ@HIDDEN> Date: Sat, 11 Jan 2025 12:06:12 +0100 Message-ID: <87v7ulmwyj.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74879 Cc: Dmitry Gutov <dmitry@HIDDEN>, 74879 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Stefan Kangas <stefankangas@HIDDEN> writes: > Dmitry Gutov <dmitry@HIDDEN> writes: > >>> - I think we do want some kind of hook, with which we can have (for >>> instance) `emacs-lisp-mode` tell Emacs to trust the user init file, >>> the early-init file, the custom-file, and all the files in >>> `load-path`. >> >> Speaking of, it would be nice to see someone formulate the thread model >> we're trying to handle this way. > > No one did that, as far as I know. > > In informal terms, the main problem is files you download online (e.g., > from a website or in a Git repository), that could come from a > potentially malicious source. > > OTOH, `trusted-files' does not really do anything to protect against > malicious ELPA packages. We need to start compiling them in a sandbox > (e.g., bwrap), and it's likely that we'll also need to take some special > precautions with autoloads. But this is well-known and documented > already, I think. If I understood Stefan Monnier's bwrap suggestion correctly, it was about evaluating macros of untrusted Elisp code from an unknown source somewhere on the file system. ELPA packages can be trusted more for multiple reasons: 1. They come from known sources, from curated archives. Admittedly the archive review is not sufficient. I've suggested to add review facilities to package.el, see bug#74604. Furthermore I've suggested to add git commit signature checks to GNU/NonGNU ELPA, see bug#61277. 2. There is the barrier of adding untrusted archives to the `package-archives' list. The user has to opt-in explicitly to that. 3. Installation of packages is confirmed via package.el and does not happen without user consent. As soon as the user agrees to install a package, they agree that the package will shortly become part of the `load-path', and that its code will be executed shortly. If we believe that package installation is not safe enough, additional louder confirmations and warnings could be added: When adding new archives (additional validation of `package-archives') and second and when installing or upgrading packages. For example `package-upgrade-all' tells me how many packages it wants to upgrade but not even which packages - I really want to inspect the list of upgradeable packages first. Which additional benefits do you see if ELPA packages are compiled inside bwrap? The trust will only be pushed a little to the future. Then additional confirmation will be needed for the autoloads and not much is won. As soon as an autoload is confirmed, the package is trusted. Instead of doing that, asking the user earlier (before download and latest before compilation) is as good or even better since then the untrusted code does not even hit the ~/.emacs.d/elpa directory. See in particular bug#74604, where the quick review could happen before installation. Daniel
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 11 Jan 2025 09:56:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 11 04:56:10 2025 Received: from localhost ([127.0.0.1]:41332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tWYDy-00029e-F3 for submit <at> debbugs.gnu.org; Sat, 11 Jan 2025 04:56:10 -0500 Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]:55513) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1tWYDw-00029G-Qz for 74879 <at> debbugs.gnu.org; Sat, 11 Jan 2025 04:56:09 -0500 Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-5d437235769so4597706a12.2 for <74879 <at> debbugs.gnu.org>; Sat, 11 Jan 2025 01:56:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736589362; x=1737194162; 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=Nn6R/fflt71hmR73ZXSF0DIhhaaAwNkqASZutk7QX0Y=; b=ZVofSMr7RkA8pU1HebU8m4hHRYE2ttaJB42qE0TNQaPPveL6w4E2IgqqNkAfjkhryb FuA22+Ujcu0O1xQXGzYqD5ZBb1xiO8yioKr3PJP1wMGlQrxJKkEqhNQDg6ggmy6E3Fu3 IWudl1emWcjnoq9vWSfK0UEvSDkN9jeQf1LkU6c7zMLSGvX2WWgrelOPaortv+njGIYO JdaAfpnC0cI+ztdg2ivCt3zNa5OleY9rGv1yOLTOMeCM+tXArlYM4xO3UySclihJdzRf kTxsd4U/ALVz5QHXsl1JZfU5Zw7JSuOT4QaJyr9m7CE3MQPMfR+PH6Itmi9ElWVnhl2a orTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736589362; x=1737194162; 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=Nn6R/fflt71hmR73ZXSF0DIhhaaAwNkqASZutk7QX0Y=; b=nac4PYSEGXnZ/W3DNGczrNlbF4QoLxfQOjQ6pJDT6mkb8sNnow2ktYDwT/FKng0DDR 6OVsacL8fEO3NppwTwEZ8uC8iFTI636HIKs1VTv20l7EsyR15BbFY0CHfnCkOp6RzX8l rS15qy0qO10nnHx3QjLOiQfcCW1+DpP942Vo2AWvogQbQHBBbERHhd8t1cbHI2CHZ8nk sx2PibWmNxFbQFaCLiEToxif3JsyM/2O5R4Ue1UyqfvILX+WzyiiCpBlZul/Jr25ScRh oevzQTzkJmx6CIFkAiufGyTW0cXojk8EXoIruOMe5QhM/Ly0o3kCGeIZSUulg9qN0Qtg ihfQ== X-Gm-Message-State: AOJu0YzcoucGGZyI2dI9aC8UyNZYQXIoS5YV1DAv/twypf/26Osv28dr wBXoU4xrOPP502iVYqIw4PBqJ61Tg+k98Judf/rnO9M4Y/QPyuuyzdk/S56nl9NL/VfNSgdm1yq HWlWhgGrkX/wwx/peSC9lgSXcFEc= X-Gm-Gg: ASbGnctH07Vl/udPSGs2DvR9rPRPWQv33PvnVzQQoD/2tAklq93+iBB3AtidBSJzsQk +LLDg9YFM9fZVn8CepnLcbpAt6itXw68it07cLSpm X-Google-Smtp-Source: AGHT+IFWFY1D+aV7gNslLNzG8TrssNE45N2NPr0gocdYDk1hvQiW6rZZ2JL4ga/YjnLoOJucVmxnme4wMvMRJkVT3mY= X-Received: by 2002:a05:6402:51d0:b0:5d1:2652:42ba with SMTP id 4fb4d7f45d1cf-5d972e1c543mr13268667a12.16.1736589361632; Sat, 11 Jan 2025 01:56:01 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 11 Jan 2025 01:56:01 -0800 From: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <e41a4abc-f095-4c9f-b25f-57ecfbd39a59@HIDDEN> References: <87ed29ixu8.fsf@HIDDEN> <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> <e41a4abc-f095-4c9f-b25f-57ecfbd39a59@HIDDEN> MIME-Version: 1.0 Date: Sat, 11 Jan 2025 01:56:01 -0800 X-Gm-Features: AbW1kvZUEU6lbmlqLEZltAxGqhdQgqvV13Zp6NOJiBy5XhQr3MEnPNqhIV6O-H4 Message-ID: <CADwFkm=gO_HZwXnMBGbwvhKL99z9nQtxShmDcgK0WmZ_5dFrBQ@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers To: Dmitry Gutov <dmitry@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, Daniel Mendler <mail@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 74879 Cc: 74879 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.3 (/) Dmitry Gutov <dmitry@HIDDEN> writes: >> - I think we do want some kind of hook, with which we can have (for >> instance) `emacs-lisp-mode` tell Emacs to trust the user init file, >> the early-init file, the custom-file, and all the files in >> `load-path`. > > Speaking of, it would be nice to see someone formulate the thread model > we're trying to handle this way. No one did that, as far as I know. In informal terms, the main problem is files you download online (e.g., from a website or in a Git repository), that could come from a potentially malicious source. OTOH, `trusted-files' does not really do anything to protect against malicious ELPA packages. We need to start compiling them in a sandbox (e.g., bwrap), and it's likely that we'll also need to take some special precautions with autoloads. But this is well-known and documented already, I think. > Indeed, should add files in load-path be considered "trusted"? If yes, > why not do this automatically. If no, then what do we think about a > scenario when a "trusted" file ends up loading a file from load-path > which redefines some standard macro. I haven't seen any arguments for why we shouldn't mark files in `load-path' trusted, so my guess is that the answer is "yes". I couldn't give you a solid reason for why we're not already doing this automatically, myself. However, there is clearly a difference between malicious code running when loading a file, and when merely visiting it.
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 18 Dec 2024 14:11:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 18 09:11:26 2024 Received: from localhost ([127.0.0.1]:33999 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tNulq-0005UM-27 for submit <at> debbugs.gnu.org; Wed, 18 Dec 2024 09:11:26 -0500 Received: from fout-b2-smtp.messagingengine.com ([202.12.124.145]:57289) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1tNuln-0005U4-1E for 74879 <at> debbugs.gnu.org; Wed, 18 Dec 2024 09:11:24 -0500 Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfout.stl.internal (Postfix) with ESMTP id 33E8C11401A8; Wed, 18 Dec 2024 09:11:17 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-11.internal (MEProxy); Wed, 18 Dec 2024 09:11:17 -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=1734531077; x=1734617477; bh=Q2+B8VcjQrAT/qqeZTbluG+/QmIo4evTrLpRP45WeuA=; b= ENE5wc6Ug8rKsaSXl/uzBKZidpaOighb0bCC+S/gMhMr71WhocuXn6KXRv4/GKCf McLtndBK+ZL6vSRN1poMAWnOEhULpJO568TRTcPo+KBtHYhgh3qxwMbW7ukrA2P1 gSDkya9cwmzmOv9G52/jYd4AOmtBXpei/s3H08LWVpMMOAMLH/zRkjOpBNGty9TA k3ZpItOjk28R8xqSSjKAXIAl3XWTlUQ3qZO4BMiQYmHklWr+VjSg6dyqgHvMyhEk XWcL1n07bykAWcw1pst/Yp/Q6fAWWLyZUq5DA+uyK2rk5VoEkhxaSiF1Xhrp0PzM Yro/HTK6hNuMrbt4noZZSw== 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=1734531077; x= 1734617477; bh=Q2+B8VcjQrAT/qqeZTbluG+/QmIo4evTrLpRP45WeuA=; b=R OJrYoQ5O08om1ru1X4xN1TegCLziB3bcwN5RUea0UkiYCzT0/ac3F66CnRZ03OeC 2VClphwn0tEr9fJI4eV5UP4zvGk7YEsZ25u295ffsR4KMIYWHT9n86w+8vDvtXx0 fqADU9kZepezKCyULl9DfXftQKcQBYspTnz5hYc6tWpq6e6xBjG49CsjbD3nHChG xuCIb45DjwJ31FpCkhL/WTuesEwa5KwEVBgEMLbev1mPcLN7dOifeLg1KU6eC19P Zq5TRnN2J4mturWJjk3T2oCmNV/yqLrOMLUwIsNdhRo/iODUq5OizPbWigrPeiyH mH0ICBwfPwfoBSCZRjfKQ== X-ME-Sender: <xms:BNhiZ1HuLKGW26fvTDc3ATFyXfjBsBOKc935USxeTcRgor29h_MLDA> <xme:BNhiZ6Va4Da4d2X-crNY59KQ_8BRr1r8-kCDLecNyPVX_aRGO-EqkUUmqDNk2_6AL IvL-WWfq9xSw2wechs> X-ME-Received: <xmr:BNhiZ3Iuc4xdN8jdARv-G31cMf_jk4mdmR7Blf9feo9KDHS-DkSiTEkfHK-xNLwljqVHKw> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrleekgdeitdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeen ucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvg hvqeenucggtffrrghtthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedt vddtveefhfdvveegudejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohep fedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepmhhonhhnihgvrhesihhrohdruh hmohhnthhrvggrlhdrtggrpdhrtghpthhtohepmhgrihhlsegurghnihgvlhdqmhgvnhgu lhgvrhdruggvpdhrtghpthhtohepjeegkeejleesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: <xmx:BNhiZ7GewDoZcq7aJNPUEmpz0nyEYYEibIM9tzhgWc6XLiwElfiwSw> <xmx:BNhiZ7VbBhiiFxT2fbIed7eDCH5VwzbCoC6W88DNSF6_82D6VovxHQ> <xmx:BNhiZ2NG3PJMi7wbLOg35Tqcmm0lrv6I72VBoQuFjHoX-mCkN5YkXw> <xmx:BNhiZ6176H5HQ33IKgjpPsiRMK0GsrIl2JP4WVsfcAlH24gdCnsAQg> <xmx:BdhiZ2T1E61loaCgADSs8HJyqvmiDS3-UFTzmXKU2ffVquBFhiHCWmJs> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 18 Dec 2024 09:11:15 -0500 (EST) Message-ID: <e41a4abc-f095-4c9f-b25f-57ecfbd39a59@HIDDEN> Date: Wed, 18 Dec 2024 16:11:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers To: Stefan Monnier <monnier@HIDDEN>, Daniel Mendler <mail@HIDDEN> References: <87ed29ixu8.fsf@HIDDEN> <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74879 Cc: 74879 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hi Stefan, On 15/12/2024 16:03, Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: >> Thank you for the recent addition of `trusted-content-p'. Is there a >> possibility to use `trusted-content-p' in buffers which are not backed >> by a file? I use Flymake in *scratch* or similar buffers and it seems >> that this won't continue to work given that `trusted-content-p' needs a >> `buffer-file-truename'. > > Good question. > We don't really have a good answer yet, AFAIK, in large part because we > don't have enough experience with it. > Off the top of my head, here are some elements relevant to this > discussion, in random order: > > - The current setup is a kind of "minimal" change for Emacs-30 because > it's late in the pretest, so as much as possible we should separate > the discussion into what's a simple enough solution for Emacs-30 and > what we should use in the longer term. That was indeed quite abrupt, for a problem that's been with us at least since 2017 (the use of flymake-elisp-byte-compile in emacs-lisp-mode). > - I think we do want some kind of hook, with which we can have (for > instance) `emacs-lisp-mode` tell Emacs to trust the user init file, > the early-init file, the custom-file, and all the files in > `load-path`. Speaking of, it would be nice to see someone formulate the thread model we're trying to handle this way. Indeed, should add files in load-path be considered "trusted"? If yes, why not do this automatically. If no, then what do we think about a scenario when a "trusted" file ends up loading a file from load-path which redefines some standard macro.
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 18 Dec 2024 00:05:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 17 19:05:32 2024 Received: from localhost ([127.0.0.1]:60778 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tNhZD-00065W-Et for submit <at> debbugs.gnu.org; Tue, 17 Dec 2024 19:05:32 -0500 Received: from mail-ej1-f48.google.com ([209.85.218.48]:53656) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1tNhZA-00065F-9m for 74879 <at> debbugs.gnu.org; Tue, 17 Dec 2024 19:05:29 -0500 Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-a9a977d6cc7so788359666b.3 for <74879 <at> debbugs.gnu.org>; Tue, 17 Dec 2024 16:05:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734480267; x=1735085067; 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=zuAiK9OS5e0TI8vnR9uzNyKWU406Y4R68kgtVl2HcuI=; b=I4Po8uACyWLJjIaAUkX7OJVwCbAMtQ6N1Yo60hoKij3lDZSXl0PX3B+9UMAJAyCQhw CMMxcKyGiPVrxPfOjhQH0Y3cXvFtItmhFEpTdy+LevnXGH4wylG7N3T4wGmwLGxFGJfv S1Y/Lrm6840IxejHWTzDoyXr/VxL1YVNY1J/778UINyyPpTkbSJ8Rh1lArxj6VBuqtcw 1TzuXRXvI87vaRGQXu7ylXtyfTm8g3kF+Ay1w1YwKEBgiKCrk3cXf+EMrwiu2eurWMIY ABJIFNeH6wxLcwZPoY8kFyvYeLA/+v0SgAAcvyKPRUFLDOI+Tn2elfiPdwg+FJYfGixU vuNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734480267; x=1735085067; 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=zuAiK9OS5e0TI8vnR9uzNyKWU406Y4R68kgtVl2HcuI=; b=J1YjsiBQwxNRNI8Xh2VFEaA6fok5gVa5Z+TaR0Ep2qRdiXEAz5ETtUmANxqWRp94fY wGDO6oZ+9iObhDwcjL/mr25c+l8WynHefP9I6yXidE0oeI7NKbV3VVA1uMlTNBDLKmeu klmr5OUCI+TWQDoDGZJnvFQosEKNU4qJAmbBxf5989T9CXZiHoJXaZicKEPCeDeiWf7T 1nS2oOfgr81WxeRKSjcdI57QapJQtSyap3LDTjJJZuJqijQmpfNW/U/2po7+44WHEum1 CajylUQ2ELLWh6boXlCBOxaMXOaG7IgJXcFpHljCb/ZHEgerbMB01tyPOvFF2jJuDPKR yI/Q== X-Forwarded-Encrypted: i=1; AJvYcCXLZ8JFBafLme/9RKnFjJAVFVJbMlyAgpOyzjA9bywRw193U9Be0MWJ628u/HrfQxF+0iorpw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyIh4nPRgmFa1TikhH1vpLoJBfwowzvyWDaTRGOae3CkmlF+08c DtC4cEDAQG91XmqnayqDMysHHGwQX1wEY95sTUSsKfcPIMoft297vnqxuGnfg10VgzG8ukG18B2 xktJUUlRcCJ6I3PjEuFoXzmkaqw0= X-Gm-Gg: ASbGncs8iKbJGUPDfwxp+1D1rnu3iyRIRkbt0vVBzbcRFA+6ejIxZNRG978qibwfhKW yTnVCcqUBc/IbL7KtvJ+tvZyPsvUGdRO9vy3jzg== X-Google-Smtp-Source: AGHT+IHNmus0vaJdi3Y4AjgkdrKX0E8JXnOEi5PQ+5ClQ8NExq0ePmF0JJqyc7SJlMWS1gSn4ZVD4Trr8wNlVlwXhW0= X-Received: by 2002:a05:6402:2691:b0:5d0:abb8:7a3 with SMTP id 4fb4d7f45d1cf-5d7ee37b12amr2343200a12.6.1734480266903; Tue, 17 Dec 2024 16:04:26 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 17 Dec 2024 16:04:26 -0800 From: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <87a5cu8b23.fsf@localhost> References: <87ed29ixu8.fsf@HIDDEN> <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> <87msgw94fz.fsf@HIDDEN> <jwv5xnkshy1.fsf-monnier+emacs@HIDDEN> <m11py8rrn9.fsf@HIDDEN> <m1seqnrede.fsf@HIDDEN> <jwvwmfzput9.fsf-monnier+emacs@HIDDEN> <CADwFkm=in74k2+j+ohwUB05QFnCc7cJ_XTK1kCh2vAZ6d1ki=A@HIDDEN> <87a5cu8b23.fsf@localhost> MIME-Version: 1.0 Date: Tue, 17 Dec 2024 16:04:26 -0800 Message-ID: <CADwFkmnHNxbwm7dvR40KS=kLHbx6zcYMwzxknQ=nXJQs34qavg@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers To: Ihor Radchenko <yantar92@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74879 Cc: Daniel Mendler <mail@HIDDEN>, 74879 <at> debbugs.gnu.org, Eshel Yaron <me@HIDDEN>, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Ihor Radchenko <yantar92@HIDDEN> writes: > Stefan Kangas <stefankangas@HIDDEN> writes: > >>>> org-latex-preview in org.el still checks for untrusted-content >>>> directly though, I wonder if it'd make sense for it to check for >>>> trusted-content-p instead. >>> >>> I can't remember the details of the `org-latex-preview` situation, so >>> I'll say tentatively "probably". >> >> Ihor, WDYT? > > I am happy to use whatever you decide to be the API. > For a moment, I am not sure if the API is final. For example, > `trusted-content-p' is not defined on master. Thanks. AFAIU, the API on emacs-30 is now final for Emacs 30, and can be relied on for that release. It's just waiting to be merged to master. We could/should continue to improve the API on master, but whatever changes we make there will obviously have to take care to maintain a reasonable level of backwards-compatibility.
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 17 Dec 2024 17:36:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 17 12:36:49 2024 Received: from localhost ([127.0.0.1]:60153 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tNbV2-00044k-L6 for submit <at> debbugs.gnu.org; Tue, 17 Dec 2024 12:36:49 -0500 Received: from mout02.posteo.de ([185.67.36.66]:51531) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1tNbV0-00044W-CZ for 74879 <at> debbugs.gnu.org; Tue, 17 Dec 2024 12:36:47 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 3F9F5240101 for <74879 <at> debbugs.gnu.org>; Tue, 17 Dec 2024 18:36:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1734456998; bh=MFoq02zkwMseqJHDgYe/45DREFJIfk9y9LzAiY7sr84=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=NqT8X80gxfQcIdkiJsP5J6nwtzzCdbKUlz6oZe2DXhHVamkhMZipzta5CPXJpdQcm QNr7Wv/ysVDKvFEfVAin/7nG02dwHlahCWQ6jGpA+NGw4KE5FLBMoWMEur6TXdk6Lc NDnWXCHrWOMstZzvynkq8wB2kbJtHh3vW5MqMTL/fRTVWCcuD4nMhqE3ww1IKGHr33 biaI+jK+9U7HkT9jPN9iHPkwQFjP+q7GlPHvRRNwolMOnDC+09V4HMB+ohCpFSrz+t EONdJx/S9z2FtIIrs2qTMbSLk03Ygs9TQmCwnW393gCN8by6ufXx/zG6UWEf+TDlH0 hREjpw+0r7NVA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YCPBF09zVz6tvl; Tue, 17 Dec 2024 18:36:36 +0100 (CET) From: Ihor Radchenko <yantar92@HIDDEN> To: Stefan Kangas <stefankangas@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers In-Reply-To: <CADwFkm=in74k2+j+ohwUB05QFnCc7cJ_XTK1kCh2vAZ6d1ki=A@HIDDEN> References: <87ed29ixu8.fsf@HIDDEN> <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> <87msgw94fz.fsf@HIDDEN> <jwv5xnkshy1.fsf-monnier+emacs@HIDDEN> <m11py8rrn9.fsf@HIDDEN> <m1seqnrede.fsf@HIDDEN> <jwvwmfzput9.fsf-monnier+emacs@HIDDEN> <CADwFkm=in74k2+j+ohwUB05QFnCc7cJ_XTK1kCh2vAZ6d1ki=A@HIDDEN> Date: Tue, 17 Dec 2024 17:38:12 +0000 Message-ID: <87a5cu8b23.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74879 Cc: Daniel Mendler <mail@HIDDEN>, 74879 <at> debbugs.gnu.org, Eshel Yaron <me@HIDDEN>, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Stefan Kangas <stefankangas@HIDDEN> writes: >>> org-latex-preview in org.el still checks for untrusted-content >>> directly though, I wonder if it'd make sense for it to check for >>> trusted-content-p instead. >> >> I can't remember the details of the `org-latex-preview` situation, so >> I'll say tentatively "probably". > > Ihor, WDYT? I am happy to use whatever you decide to be the API. For a moment, I am not sure if the API is final. For example, `trusted-content-p' is not defined on master. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 17 Dec 2024 11:30:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 17 06:30:28 2024 Received: from localhost ([127.0.0.1]:57798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tNVmV-0002Ex-Qb for submit <at> debbugs.gnu.org; Tue, 17 Dec 2024 06:30:28 -0500 Received: from server.qxqx.de ([49.12.34.165]:51465 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1tNVmQ-00029S-Gm for 74879 <at> debbugs.gnu.org; Tue, 17 Dec 2024 06:30:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XcvynM3dOnHGEbB3CvB32Ecrk6v/jaO/9vXjITOoaWw=; b=Td9076SawdHAgMtX1VDGNkfOYg nyr3sxtX+HvSmgkfR1r6xKCsltU9hTPDusWqk/Obtt3pIaGc5vQb3JB35Glrx1SmfOmKTER8v6y8j mQAELenBTxSZ9hoSD96tVT8EUICeNkCFE1Xvx9Gf65SYQEj+f350ANh08iGd3xK0pze0=; From: Daniel Mendler <mail@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers In-Reply-To: <e97bbc5e-eb4a-46b7-aa96-3db1a56173a2@HIDDEN> (Dmitry Gutov's message of "Tue, 17 Dec 2024 03:42:16 +0200") References: <87ed29ixu8.fsf@HIDDEN> <875xnlfdzi.fsf@HIDDEN> <643a50f9-2128-405b-ae5b-114990b3dfc2@HIDDEN> <87h6739245.fsf@HIDDEN> <e97bbc5e-eb4a-46b7-aa96-3db1a56173a2@HIDDEN> Date: Tue, 17 Dec 2024 12:30:14 +0100 Message-ID: <87h6721r95.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74879 Cc: 74879 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dmitry@HIDDEN> writes: > 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. I don't disagree with your points. For me the issue here has been solved satisfactorily given Stefan's recent changes in the emacs-30 branch, such that the trust facilities can be used in non-file buffers. As for the usefulness of the trust feature - I think one can use it for both disabling certain dangerous code like macro expansion to close a security hole, and also to adjust confirmation settings in user configurations. For example in trusted buffers or trusted files confirmation a user might want to execute Org babel or Org links directly, while this should not happen in downloaded files or buffers coming from Gnus. While disabling confirmation decreases security, disabling confirmation only in trusted buffers is still better than disabling confirmation globally. The same applies to file-local variables. In trusted files, one may want to activate file-local variables always or with confirmation, while in untrusted files, local variables should be disabled entirely or only :safe variables should be loaded. Daniel
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 17 Dec 2024 01:42:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 16 20:42:30 2024 Received: from localhost ([127.0.0.1]:56879 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tNMbV-0007Kz-UQ for submit <at> debbugs.gnu.org; Mon, 16 Dec 2024 20:42:30 -0500 Received: from fout-a8-smtp.messagingengine.com ([103.168.172.151]:40861) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1tNMbR-0007Kc-VS for 74879 <at> debbugs.gnu.org; Mon, 16 Dec 2024 20:42:27 -0500 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) 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: <xms:-9ZgZ6aOd-7KKzD3vzA9aF9GxtJBb_vgcdkvIon4GO9env0VTxbdHQ> <xme:-9ZgZ9b8DrDhSKmqmaZF0-vfIQFnWkYcTTOoc6uy8Pe47_h4hx8YX4ymUYTVyKmTY kZZHRxDWtJ-ql6r3n0> X-ME-Received: <xmr:-9ZgZ09DMg6XESoSPzRtTakeIHVYQOS6ZgrDhI1g-oN81Otl9qlJGcP2RqFADIMMsOL-FA> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrleeggdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeen ucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvg hvqeenucggtffrrghtthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedt vddtveefhfdvveegudejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohep gedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepmhgrihhlsegurghnihgvlhdqmh gvnhgulhgvrhdruggvpdhrtghpthhtohepjeegkeejleesuggvsggsuhhgshdrghhnuhdr ohhrghdprhgtphhtthhopehmohhnnhhivghrsehirhhordhumhhonhhtrhgvrghlrdgtrg dprhgtphhtthhopehsthgvfhgrnhhkrghnghgrshesghhmrghilhdrtghomh X-ME-Proxy: <xmx:-9ZgZ8oOlwf3huKMxOAgaSn3UEpjVsghNDKszsA99D5Tud1nO86gvg> <xmx:-9ZgZ1qMFv3kTEnCveY4Vuy7NS3FzWKg8wU_ekwOkvi8j8ZNFxA9Vg> <xmx:-9ZgZ6Q6kfSGwEb08_YyEsVtQNnl_IjgLroAveySlLReVrhsMsXEyA> <xmx:-9ZgZ1rhUlZNvIV0xohY5FaYTAfKv8o4sdZsfx5Hj1wrbn0-2XLwng> <xmx:_NZgZ-BltZUlBj85y0tSNYTE8421oN1204JXBWKVHvj35pe94V5sg9gO> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 16 Dec 2024 20:42:18 -0500 (EST) Message-ID: <e97bbc5e-eb4a-46b7-aa96-3db1a56173a2@HIDDEN> Date: Tue, 17 Dec 2024 03:42:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers To: Daniel Mendler <mail@HIDDEN> References: <87ed29ixu8.fsf@HIDDEN> <875xnlfdzi.fsf@HIDDEN> <643a50f9-2128-405b-ae5b-114990b3dfc2@HIDDEN> <87h6739245.fsf@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <87h6739245.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74879 Cc: 74879 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 16/12/2024 15:41, Daniel Mendler wrote: > Dmitry Gutov <dmitry@HIDDEN> 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.
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 16 Dec 2024 22:00:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 16 17:00:48 2024 Received: from localhost ([127.0.0.1]:56581 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tNJ8x-0004RB-Oq for submit <at> debbugs.gnu.org; Mon, 16 Dec 2024 17:00:48 -0500 Received: from mail-ed1-f48.google.com ([209.85.208.48]:57378) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1tNJ8w-0004R1-9h for 74879 <at> debbugs.gnu.org; Mon, 16 Dec 2024 17:00:47 -0500 Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-5d4e2aa7ea9so913355a12.2 for <74879 <at> debbugs.gnu.org>; Mon, 16 Dec 2024 14:00:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734386385; x=1734991185; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:from:to:cc:subject:date :message-id:reply-to; bh=ioXxEL/yR0yOUIfLlS8st6Q3V4qshJB/fNcwuiDC4as=; b=Jc6SZZKLv3Wy1TNuNFx+jgFxBzOaj1/JBGe0IKE/PVwD8wv1foBZl9ROA7KE0SOoK2 +By8IpiUtM4gobeaThLS6Z2tZM+SshzVpilJgLRLDOPVIvZEmZ40zqZToPYeknTEVWKD DL+zzrwAzdkbgh81rVcTkvxFFdZ9XJVBeGN9yPowCw9rPUk0lBlaENk3pGUN+YEflBgF tpr2M7kq/lq6H2NE6snVzdcyu9tUy30TGrNLHRqOwjnW7juj29+EZ/szUiFzVxxqV1ag xY+ekGRBiz55ZO1f1wWw6UogrVgvVoTcPmQsfGE5Ah0kCA2SNONYVRq+WRSu8J7KcQw5 1+jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734386385; x=1734991185; h=content-transfer-encoding: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=ioXxEL/yR0yOUIfLlS8st6Q3V4qshJB/fNcwuiDC4as=; b=BlufCNSb7diBiZ+2WsjthZJEQuHN4Q0T6MuJ3C92KM4xZfXqDS+Cg72LHuPazZfLV9 vakYtfHoJq9+T39JCVI1mgninSeCigOvpDhHdgswKOi0nnL/HH3jya0i9cmo1VP2hfEW tPS0E4+BVPFbYEjBaoYsbIXmAfBUIyk91BnO10d2bWjsm3I8Zo3U0TsV3UCQ66DH3LHi qpYJMf+clORZzyN+kN8ehqzb3RRNs8Qwrpc2di/4ExzbryrJ88JUxrBZSQoL6PlXOgV7 6yh8IdfE3qUJrxHvjlISbvWN0pbAv1E7ASvcUDsCfw/wRfH/K+4rUu0kTwrYxc9VJi9S ULwA== X-Forwarded-Encrypted: i=1; AJvYcCXJRphLsJlN3WNIUcJ3wkYe1wJESCuhxzokAizPrnUblL0tpQ6GOCtutEP1x00DgmBTfx+6KQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwiSgAf9d0VFBgmqWSn5RvimtvOOoYJ8MgUfR36CFS3C3e4B2ly WVlbvo2K6D1KGvLOFoU13jYo4h3uEGSJtlEJPeSfNAxpPODyWnKDuOZC2yx5ixK79EbfZzjywfi LHEZ/1/7s+KyL8JUmdUGVHbSsWXQ= X-Gm-Gg: ASbGnct3588Knhq9O9cou4oIxxWrUvbOkZknAGaK1MuSGT7dIJdvgHf9jx0wM7ZVn5X lRShtMQON/T0r04YEkE0+2DGAlq7AB4T4WIRJyEE= X-Google-Smtp-Source: AGHT+IGEuFTj0ZzWlCmiCOLvLtqZujzVKfPe5mQVjXAong4ur/0NjfAQ6JqSMUOaJqBHp4/+y/lrjLFryVx19j4Vydk= X-Received: by 2002:a05:6402:3890:b0:5cf:bcaf:98ec with SMTP id 4fb4d7f45d1cf-5d63c3a96a7mr13423434a12.26.1734386385285; Mon, 16 Dec 2024 13:59:45 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 16 Dec 2024 21:59:45 +0000 From: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <jwvwmfzput9.fsf-monnier+emacs@HIDDEN> References: <87ed29ixu8.fsf@HIDDEN> <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> <87msgw94fz.fsf@HIDDEN> <jwv5xnkshy1.fsf-monnier+emacs@HIDDEN> <m11py8rrn9.fsf@HIDDEN> <m1seqnrede.fsf@HIDDEN> <jwvwmfzput9.fsf-monnier+emacs@HIDDEN> MIME-Version: 1.0 Date: Mon, 16 Dec 2024 21:59:45 +0000 Message-ID: <CADwFkm=in74k2+j+ohwUB05QFnCc7cJ_XTK1kCh2vAZ6d1ki=A@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers To: Stefan Monnier <monnier@HIDDEN>, Eshel Yaron <me@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74879 Cc: Daniel Mendler <mail@HIDDEN>, Ihor Radchenko <yantar92@HIDDEN>, 74879 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> writes: >> Sorry, I now realize that they are already consolidated in the sense >> trusted-content-p considers both variables. > > It's a limited form of consolidation, but indeed I did try and do a bit > of it. =F0=9F=99=82 > >> org-latex-preview in org.el still checks for untrusted-content >> directly though, I wonder if it'd make sense for it to check for >> trusted-content-p instead. > > I can't remember the details of the `org-latex-preview` situation, so > I'll say tentatively "probably". Ihor, WDYT?
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.
Received: (at 74879) by debbugs.gnu.org; 16 Dec 2024 18:48:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 16 13:48:56 2024
Received: from localhost ([127.0.0.1]:56175 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tNG9H-0002SG-QC
for submit <at> debbugs.gnu.org; Mon, 16 Dec 2024 13:48:56 -0500
Received: from server.qxqx.de ([49.12.34.165]:60891 helo=mail.qxqx.de)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <mail@HIDDEN>) id 1tNG9F-0002Rx-4r
for 74879 <at> debbugs.gnu.org; Mon, 16 Dec 2024 13:48:54 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date:
References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:
Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:
Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:
List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
bh=MRYXb5Ge82C1fzS/xqWzj6kfeSwkMfvO5LrLkNms724=; b=DRoGj5G1HDDsoqIw3Y8kgW33kl
LzUX2EYf3Rd4hDjBQ7uknajLh/5bKP8NwCbUSFbLxOCT3P4bAxuL9bmS7YbDQFKkgIrApF0OYK9fY
pyn3oOW5+DsBrcaxMwQBoPVh869H+SC1Vmvo7lcHyKgjp8/kwG63nUqVMUvCKRV3/sJw=;
From: Daniel Mendler <mail@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot
be used for non-file buffers
In-Reply-To: <jwvr067puml.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
of "Mon, 16 Dec 2024 09:43:54 -0500")
References: <87ed29ixu8.fsf@HIDDEN>
<jwvikrlukf7.fsf-monnier+emacs@HIDDEN>
<87msgw94fz.fsf@HIDDEN>
<jwv5xnkshy1.fsf-monnier+emacs@HIDDEN>
<87v7vk562i.fsf@HIDDEN>
<jwvr067puml.fsf-monnier+emacs@HIDDEN>
Date: Mon, 16 Dec 2024 19:48:44 +0100
Message-ID: <87jzbz79bn.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74879
Cc: 74879 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
Stefan Monnier <monnier@HIDDEN> writes:
>> The thought was rather that auto completion may be dangerous in general
>
> Maybe I have too narrow a view of completion, but my impression is that
> completion is usually safe. The situation in ELisp where we perform
> macro expansion to try and get the set of local variables in scope and
> where that macro expansion can end up running local code is rather
> unusual, AFAIK.
Agree.
> What kind of situation are you thinking of where completion is unsafe?
Elisp completion on Emacs 29 and older for example ;)
>> I just took another look at the `trusted-content-p' function on the
>> emacs-30 branch:
>>
>> (defun trusted-content-p ()
>> (and (not untrusted-content)
>> buffer-file-truename
>> ...))
>>
>> There is a check for `buffer-file-truename' which means that the issue
>> with non-file-backed buffers remains (Ielm or scratch). Probably (eq
>> trusted-content :all) should be checked first?
>
> Duh! I forgot that the same change toned down the warnings, so I
> didn't look at the right place when "testing". Thanks for the heads up,
> I just fixed it in `emacs-30`.
Thanks for pushing the fix.
>> At the same time one could consolidate the untrusted-content and
>> trusted-content variables as Eshel suggested?
>>
>> (defun trusted-content-p ()
>> (and (not untrusted-content) ;; only for backward compat (deprecated)
>> (not (eq trusted-content :untrusted)) ;; replaces untrusted-content
>> (or (eq trusted-content :all)
>> (and buffer-file-name
>> ...))))
>
> I could go along with that (not for `emacs-30`, tho).
> I'd prefer to get a bit more experience before deciding to do that, tho.
Okay, sure. No urgency about that one.
Just to give some examples where the new trust function could be useful,
assuming that the user really trusts their trusted files:
(setq org-confirm-babel-evaluate (lambda (&rest _)
(not (trusted-content-p)))
org-link-elisp-confirm-function (lambda (prompt)
(or (trusted-content-p)
(y-or-n-p prompt)))
org-link-shell-confirm-function org-link-elisp-confirm-function)
Maybe it is possible to configure `enable-local-variables' similarly.
Daniel
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.
Received: (at 74879) by debbugs.gnu.org; 16 Dec 2024 14:44:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 16 09:44:06 2024
Received: from localhost ([127.0.0.1]:54095 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tNCKL-0005Lm-Q8
for submit <at> debbugs.gnu.org; Mon, 16 Dec 2024 09:44:06 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42774)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1tNCKJ-0005L8-3R
for 74879 <at> debbugs.gnu.org; Mon, 16 Dec 2024 09:44:04 -0500
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 427341000BD;
Mon, 16 Dec 2024 09:43:57 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1734360236;
bh=L6+6X39pcqpdyZ9APiRw33DQ1z9iHs6gdnyiPnJ2h78=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=obDNpcmdxg+mVUCPdvH7XvUrDrCPwIXUmqMpEx0f8nP+3KsZcAG6oR66iwa5sgh6P
LLAIcvnlYixinIdsGkW7328MRF7x1bbYVFdh3KzQve2b5TQSltRm1UokvaxULT5+KU
JzK5bswMCTLCWqKgB1gPEw5AMGm3g9nbnO3+BpfDLgOqVjdTItNtocqJNm0YSbOYCR
TdaxHQZ5WpBgxs58NeM5uH9T4ySAqwMdfYgc1nva5dnTsrRTpejZ3iqY5AjTpBb4oD
IXBSZ3FMZP16IDDUf8LSIbNA9tbHH4deAB6VDAtdE9aNfaqmFXtJ04jDB2pgEILtDV
5tp6D7KlbdxoQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5D8BD100042;
Mon, 16 Dec 2024 09:43:56 -0500 (EST)
Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 32437120611;
Mon, 16 Dec 2024 09:43:56 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Daniel Mendler <mail@HIDDEN>
Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot
be used for non-file buffers
In-Reply-To: <87v7vk562i.fsf@HIDDEN> (Daniel Mendler's message of
"Mon, 16 Dec 2024 10:29:41 +0100")
Message-ID: <jwvr067puml.fsf-monnier+emacs@HIDDEN>
References: <87ed29ixu8.fsf@HIDDEN>
<jwvikrlukf7.fsf-monnier+emacs@HIDDEN>
<87msgw94fz.fsf@HIDDEN>
<jwv5xnkshy1.fsf-monnier+emacs@HIDDEN>
<87v7vk562i.fsf@HIDDEN>
Date: Mon, 16 Dec 2024 09:43:54 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.031 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 74879
Cc: 74879 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> I can live with that for now.
>> It's probably not much worse than
>>
>> (add-function :override (local 'trusted-content-function) #'always)
>>
>> [ BTW, I just renamed the var to `trusted-content`. ]
>
> I think it is not as good as a central configuration variable where I
> configure the trust for buffers or files. Now configuring trust is
> scattered across multiple major modes. My proposal was for a global hook
> variable which is consulted by `trusted-content-p' and then checks
> certain trust list for files or buffers. This way it is easier to check
> what we are trusting.
Both `trusted-content-function` and `trusted-content-functions` would be
"normal" hooks in the sense that they are neither specifically global
nor specifically local: the code that adds elements to it get to choose
whether to add it buffer-locally or globally.
For major modes, it makes a lot more sense to add elements locally,
since that avoids having to worry about the performance impact on the
rest of Emacs and things like that.
> The thought was rather that auto completion may be dangerous in general
Maybe I have too narrow a view of completion, but my impression is that
completion is usually safe. The situation in ELisp where we perform
macro expansion to try and get the set of local variables in scope and
where that macro expansion can end up running local code is rather
unusual, AFAIK.
What kind of situation are you thinking of where completion is unsafe?
> My initial proposal was about a global `trusted-buffer-functions' hook
I don't see any reason to restrict such a hook to be global.
> but I may have not communicated this clearly enough. I have two problems
> with the buffer-local approach:
The `trusted-buffer-function` I sketched would similarly not be
restricted to be buffer-local. IOW local/global is orthogonal to
whether we go with `trusted-buffer-functions` or
`trusted-buffer-function`.
> I just took another look at the `trusted-content-p' function on the
> emacs-30 branch:
>
> (defun trusted-content-p ()
> (and (not untrusted-content)
> buffer-file-truename
> ...))
>
> There is a check for `buffer-file-truename' which means that the issue
> with non-file-backed buffers remains (Ielm or scratch). Probably (eq
> trusted-content :all) should be checked first?
Duh! I forgot that the same change toned down the warnings, so I
didn't look at the right place when "testing". Thanks for the heads up,
I just fixed it in `emacs-30`.
> At the same time one could consolidate the untrusted-content and
> trusted-content variables as Eshel suggested?
>
> (defun trusted-content-p ()
> (and (not untrusted-content) ;; only for backward compat (deprecated)
> (not (eq trusted-content :untrusted)) ;; replaces untrusted-content
> (or (eq trusted-content :all)
> (and buffer-file-name
> ...))))
I could go along with that (not for `emacs-30`, tho).
I'd prefer to get a bit more experience before deciding to do that, tho.
Stefan
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.
Received: (at 74879) by debbugs.gnu.org; 16 Dec 2024 14:31:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 16 09:31:23 2024
Received: from localhost ([127.0.0.1]:54070 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tNC83-0004ih-3B
for submit <at> debbugs.gnu.org; Mon, 16 Dec 2024 09:31:23 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:56143)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1tNC7z-0004iP-8V
for 74879 <at> debbugs.gnu.org; Mon, 16 Dec 2024 09:31:21 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 69244442B47;
Mon, 16 Dec 2024 09:31:11 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1734359470;
bh=zcn2B4yMstaBJmA8/niWFcNxm2a1lYNAVnraHR/9Vuk=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=UJKglHWMMHaUVknpRfchkusuwwy+bDUzTyx/WMOMD9o2zE6qubOEA5JK8iKSBvrXM
dtqe6wlsfZ0EAAplUeux/mco3yYPF1UIEAchK7g4z6k7fzxztesVBigF4uoC5Z2xdF
oTckiZGJ17iqUcOuCinqUNDqePyxOLHPQce+YAlduMB5zYXw66ICyTZK7hCXqs8cfY
nWpGOqCzMkCsUtTCOrFaj8eAgGiIlsG8k8fG8YrLn2qD6Pp+IzGt/ztvRBBRSGMu5Z
RvDaet3sRMIML2ZyYwgmizpi1UoO78uOA0XaF5cDvJVVYPJ/iz5DR05zhiretxKY9x
EenJ8dptBBISg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 523AE442A54;
Mon, 16 Dec 2024 09:31:10 -0500 (EST)
Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 24F3C12026C;
Mon, 16 Dec 2024 09:31:10 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Eshel Yaron <me@HIDDEN>
Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot
be used for non-file buffers
In-Reply-To: <m1seqnrede.fsf@HIDDEN> (Eshel
Yaron's message of "Mon, 16 Dec 2024 13:39:25 +0100")
Message-ID: <jwvwmfzput9.fsf-monnier+emacs@HIDDEN>
References: <87ed29ixu8.fsf@HIDDEN>
<jwvikrlukf7.fsf-monnier+emacs@HIDDEN>
<87msgw94fz.fsf@HIDDEN>
<jwv5xnkshy1.fsf-monnier+emacs@HIDDEN>
<m11py8rrn9.fsf@HIDDEN>
<m1seqnrede.fsf@HIDDEN>
Date: Mon, 16 Dec 2024 09:31:08 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.007 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 74879
Cc: Daniel Mendler <mail@HIDDEN>, 74879 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Sorry, I now realize that they are already consolidated in the sense
> trusted-content-p considers both variables.
It's a limited form of consolidation, but indeed I did try and do a bit
of it. =F0=9F=99=82
> org-latex-preview in org.el still checks for untrusted-content
> directly though, I wonder if it'd make sense for it to check for
> trusted-content-p instead.
I can't remember the details of the `org-latex-preview` situation, so
I'll say tentatively "probably".
Stefan
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 16 Dec 2024 13:41:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 16 08:41:42 2024 Received: from localhost ([127.0.0.1]:53997 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tNBLx-0001wY-Me for submit <at> debbugs.gnu.org; Mon, 16 Dec 2024 08:41:42 -0500 Received: from server.qxqx.de ([49.12.34.165]:59029 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1tNBLv-0001wH-2S for 74879 <at> debbugs.gnu.org; Mon, 16 Dec 2024 08:41:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IdR9fiFDZj9uXSGNuPxJD9MsBT1/Vy/1Tc/Zq5w7nGs=; b=fcfphyqGf+achiCM2QarbKZ6v5 IVBOyWe1tjoFuHBXwGnZVsBcq5ZwpAGxhcQuUbOpNSW3OXmDVN6HfPnOzmiN06YfHR/4fou6JX45a uDAbLsxX9arIF44EKJoMlFCPS3vg6TCDOm/728IOdxMATCT3NLxlWzSze9w/DWs5xgCA=; From: Daniel Mendler <mail@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers In-Reply-To: <643a50f9-2128-405b-ae5b-114990b3dfc2@HIDDEN> (Dmitry Gutov's message of "Mon, 16 Dec 2024 15:32:31 +0200") References: <87ed29ixu8.fsf@HIDDEN> <875xnlfdzi.fsf@HIDDEN> <643a50f9-2128-405b-ae5b-114990b3dfc2@HIDDEN> Date: Mon, 16 Dec 2024 14:41:30 +0100 Message-ID: <87h6739245.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74879 Cc: 74879 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dmitry@HIDDEN> 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. >>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. Daniel
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 16 Dec 2024 13:32:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 16 08:32:44 2024 Received: from localhost ([127.0.0.1]:53983 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tNBDI-0001Ry-Hi for submit <at> debbugs.gnu.org; Mon, 16 Dec 2024 08:32:44 -0500 Received: from fhigh-b5-smtp.messagingengine.com ([202.12.124.156]:60981) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1tNBDG-0001Ri-1Y for 74879 <at> debbugs.gnu.org; Mon, 16 Dec 2024 08:32:43 -0500 Received: from phl-compute-06.internal (phl-compute-06.phl.internal [10.202.2.46]) by mailfhigh.stl.internal (Postfix) with ESMTP id 3362E2540161; Mon, 16 Dec 2024 08:32:36 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Mon, 16 Dec 2024 08:32:36 -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=1734355956; x=1734442356; bh=AkRtIKmFDpTaKPAR80LOjZppfoygEOtOTpAjN0FbS48=; b= Eqtd9+eVeRrax2iAF8etHE+lxk5HqiMFJ4WNrC+ikUcxmdgMB9XJzL8Gdh58vG+r T7m2TTGVbLyNhj5KElP2eV/coiy3sD2B1RXzo4SvNIHOkvgJKsa0JxOe2+oz+IWd 1tMgNBCf8uICuzPMvIF2ypJ+eoBMk71K2fz/KGwapihAuCnaRoSR0JwMRPDLmNeA iRpQuOPClpviDSbSAE5eNHrvezZpuFLUTEOQvkqReJIXArLX2E+0cHWGJcsX2gsQ wXPuT1XUO9wFELqsdqxxGSXCHm6rJEqHd2iZbDhMewfu8u2EnOYszkT7v+oZPDYd rIxgOrGIqFYdEOKgTV30Kg== 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=1734355956; x= 1734442356; bh=AkRtIKmFDpTaKPAR80LOjZppfoygEOtOTpAjN0FbS48=; b=O DcUJUPsIM9/f+qWa1QdulwbhqTZ6vXP8QqWUyrSiuabDaK17e76gpwrCHnhRvRUd D+rdDijUoAw1dXkfeU2zNW2BxrYDcoeNuqhPTZOr13qxs+ZVbJZVzJr6M4NMT7QD wd4cA7OWmUSXJQ4UEKIlLng6PUeeGcKv+E/vC3cpy47v+gMOiO2iVBnR7PYVukxF 4u24Gjh53+KM5TesANTCyg+2G0SvNM3NgG0pooeO7PYfFofrgO/ntBqTzKPSxeY+ HFwd4xsauJJfZnGC5B3nJPmGws5famJTGptI6nqroGzihUTHll4AkAldICpjXNFs taoj1oyd4FZRCEbnwZVqQ== X-ME-Sender: <xms:8ytgZ6NhwUwMhF3XCy77A1plluUHy5r99270EOcX3oJtRiNwPHa4Ew> <xme:8ytgZ48gSRAaY5E4YXbGGvKfz1XHwqbRYw_kDjUeKDo7cn9dsZ_AtI3c7vChccXXn KGbAuSRen86RLCSGTo> X-ME-Received: <xmr:8ytgZxSvl5-eJJahLEIE1G4RNh1YJclacA91GURGSNn9IAz46XQ8EkgMN4LsdsScyszyFQ> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrleefgdehfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeen ucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvg hvqeenucggtffrrghtthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedt vddtveefhfdvveegudejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohep gedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepmhgrihhlsegurghnihgvlhdqmh gvnhgulhgvrhdruggvpdhrtghpthhtohepjeegkeejleesuggvsggsuhhgshdrghhnuhdr ohhrghdprhgtphhtthhopehmohhnnhhivghrsehirhhordhumhhonhhtrhgvrghlrdgtrg dprhgtphhtthhopehsthgvfhgrnhhkrghnghgrshesghhmrghilhdrtghomh X-ME-Proxy: <xmx:8ytgZ6vvND6NiX3Xtf2GaNuv8ghZwdg5IKUO-G6itb9U--TP9stmDw> <xmx:8ytgZydyxYPQAUzlKB0V7nxESOxVpLeTn9NPLiGOy0b9ipm9Fiq1EA> <xmx:8ytgZ-1Aew6C9JTW1XZOsYMOlPE-DkBPIYgTxkwPCPmaFAOcWh6kFw> <xmx:8ytgZ28k6bmW3g9gyNS7NjbOgjndV8fkBj67spiarTrDaCGn_tNSQA> <xmx:9CtgZx4yq049VrLnO6xYNB7CbwCcQEx9vVAWWc7vsVmDUBiYT8_hjTbc> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 16 Dec 2024 08:32:33 -0500 (EST) Message-ID: <643a50f9-2128-405b-ae5b-114990b3dfc2@HIDDEN> Date: Mon, 16 Dec 2024 15:32:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers To: Daniel Mendler <mail@HIDDEN>, 74879 <at> debbugs.gnu.org References: <87ed29ixu8.fsf@HIDDEN> <875xnlfdzi.fsf@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <875xnlfdzi.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74879 Cc: Stefan Monnier <monnier@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) 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? >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.
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 16 Dec 2024 12:39:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 16 07:39:30 2024 Received: from localhost ([127.0.0.1]:53909 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tNANm-00074O-DX for submit <at> debbugs.gnu.org; Mon, 16 Dec 2024 07:39:30 -0500 Received: from mail.eshelyaron.com ([107.175.124.16]:41056 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <me@HIDDEN>) id 1tNANk-00074D-7u for 74879 <at> debbugs.gnu.org; Mon, 16 Dec 2024 07:39:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1734352767; bh=3+OQNyjRc4icBACQQWj3VuuPXhqY8cyD3cJOpNooeII=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=E/N/J9vegk/81JbJigT46VkRG81jjDGJ4rzU5ETQvMw3JILZ9cYIOk1XSM2QZOuew RM8U01q7fy+eA3qsdcVkjStTMSBEvK5toS3kgAFLioDIFgxTO3Bnh8f+Nkw6pzK4un 7IawMNQLsorX/6hwOy3Wmhy/tAiSd9Y6w1J3CjpE2i/Vw/zKf4maixhFDyS5YQ/n/V 1ReHM4PurjmSldqqg5Xq/90DqLD1uK2vHO9yGOre2Y3W0xN9xyQqli6/sZsuRylK/b cnYzD+pHRTtFJPm8NScS/QtqBj220AofrrfdpP3gzQq8sU6pQKEI2dW9v9QXMUk1lO ieSXTlKVO7gdw== From: Eshel Yaron <me@HIDDEN> To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers In-Reply-To: <m11py8rrn9.fsf@HIDDEN> (Eshel Yaron's message of "Mon, 16 Dec 2024 08:52:42 +0100") References: <87ed29ixu8.fsf@HIDDEN> <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> <87msgw94fz.fsf@HIDDEN> <jwv5xnkshy1.fsf-monnier+emacs@HIDDEN> <m11py8rrn9.fsf@HIDDEN> Date: Mon, 16 Dec 2024 13:39:25 +0100 Message-ID: <m1seqnrede.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74879 Cc: Daniel Mendler <mail@HIDDEN>, 74879 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eshel Yaron <me@HIDDEN> writes: > Hi, > > Thank you for your work on this mitigation! > > Stefan Monnier writes: > >> [ BTW, I just renamed the var to `trusted-content`. ] > > Note that now we have both trusted-content and untrusted-content, both > security-related but with somewhat different meanings... It might be > worth consolidating the two somehow to avoid confusion. Sorry, I now realize that they are already consolidated in the sense trusted-content-p considers both variables. org-latex-preview in org.el still checks for untrusted-content directly though, I wonder if it'd make sense for it to check for trusted-content-p instead. Eshel
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 16 Dec 2024 12:39:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 16 07:39:35 2024 Received: from localhost ([127.0.0.1]:53912 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tNANq-00074g-P0 for submit <at> debbugs.gnu.org; Mon, 16 Dec 2024 07:39:35 -0500 Received: from lists.gnu.org ([209.51.188.17]:45836) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <me@HIDDEN>) id 1tNANm-00074P-HZ for submit <at> debbugs.gnu.org; Mon, 16 Dec 2024 07:39:31 -0500 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 <me@HIDDEN>) id 1tNANm-0001s0-9P for bug-gnu-emacs@HIDDEN; Mon, 16 Dec 2024 07:39:30 -0500 Received: from mail.eshelyaron.com ([107.175.124.16] helo=eshelyaron.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <me@HIDDEN>) id 1tNANk-0002yy-OD for bug-gnu-emacs@HIDDEN; Mon, 16 Dec 2024 07:39:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1734352767; bh=3+OQNyjRc4icBACQQWj3VuuPXhqY8cyD3cJOpNooeII=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=E/N/J9vegk/81JbJigT46VkRG81jjDGJ4rzU5ETQvMw3JILZ9cYIOk1XSM2QZOuew RM8U01q7fy+eA3qsdcVkjStTMSBEvK5toS3kgAFLioDIFgxTO3Bnh8f+Nkw6pzK4un 7IawMNQLsorX/6hwOy3Wmhy/tAiSd9Y6w1J3CjpE2i/Vw/zKf4maixhFDyS5YQ/n/V 1ReHM4PurjmSldqqg5Xq/90DqLD1uK2vHO9yGOre2Y3W0xN9xyQqli6/sZsuRylK/b cnYzD+pHRTtFJPm8NScS/QtqBj220AofrrfdpP3gzQq8sU6pQKEI2dW9v9QXMUk1lO ieSXTlKVO7gdw== From: Eshel Yaron <me@HIDDEN> To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers In-Reply-To: <m11py8rrn9.fsf@HIDDEN> (Eshel Yaron's message of "Mon, 16 Dec 2024 08:52:42 +0100") References: <87ed29ixu8.fsf@HIDDEN> <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> <87msgw94fz.fsf@HIDDEN> <jwv5xnkshy1.fsf-monnier+emacs@HIDDEN> <m11py8rrn9.fsf@HIDDEN> Date: Mon, 16 Dec 2024 13:39:25 +0100 Message-ID: <m1seqnrede.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=107.175.124.16; envelope-from=me@HIDDEN; helo=eshelyaron.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: Daniel Mendler <mail@HIDDEN>, 74879 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.4 (--) Eshel Yaron <me@HIDDEN> writes: > Hi, > > Thank you for your work on this mitigation! > > Stefan Monnier writes: > >> [ BTW, I just renamed the var to `trusted-content`. ] > > Note that now we have both trusted-content and untrusted-content, both > security-related but with somewhat different meanings... It might be > worth consolidating the two somehow to avoid confusion. Sorry, I now realize that they are already consolidated in the sense trusted-content-p considers both variables. org-latex-preview in org.el still checks for untrusted-content directly though, I wonder if it'd make sense for it to check for trusted-content-p instead. Eshel
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.
Received: (at 74879) by debbugs.gnu.org; 16 Dec 2024 09:43:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 16 04:43:26 2024
Received: from localhost ([127.0.0.1]:53536 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tN7dN-0006QL-Vw
for submit <at> debbugs.gnu.org; Mon, 16 Dec 2024 04:43:26 -0500
Received: from server.qxqx.de ([49.12.34.165]:38311 helo=mail.qxqx.de)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <mail@HIDDEN>) id 1tN7dM-0006Q1-6a
for 74879 <at> debbugs.gnu.org; Mon, 16 Dec 2024 04:43:25 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date:
References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:
Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:
Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:
List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
bh=azuWFF+WnRH/D6sU3VZoP87PUfaz0rSB6Gl0NLdf7Ac=; b=LfAeoFKOj1Wpc+GypeVstqLARg
Cz/AdEBblhSPZxIOXw9LJ12S3on0U/dXZQbOk94QHkJQQ5RaQY3vJLKuR48nP7XSVAIWtEy0DvIhL
yRYVrNg6lka1x0ARHzwshpGSM7C5nSG3IIS9hB14zzgSFfkxwpL8S4aGqNS6qgk1pkYE=;
From: Daniel Mendler <mail@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot
be used for non-file buffers
In-Reply-To: <jwv5xnkshy1.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
of "Sun, 15 Dec 2024 17:41:59 -0500")
References: <87ed29ixu8.fsf@HIDDEN>
<jwvikrlukf7.fsf-monnier+emacs@HIDDEN>
<87msgw94fz.fsf@HIDDEN>
<jwv5xnkshy1.fsf-monnier+emacs@HIDDEN>
Date: Mon, 16 Dec 2024 10:43:16 +0100
Message-ID: <87wmg03qvf.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 74879
Cc: 74879 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
Hello Stefan,
I just took another look at the `trusted-content-p' function on the
emacs-30 branch:
(defun trusted-content-p ()
(and (not untrusted-content)
buffer-file-truename
...))
There is a check for `buffer-file-truename' which means that the issue
with non-file-backed buffers remains (Ielm or scratch). Probably (eq
trusted-content :all) should be checked first?
(defun trusted-content-p ()
(and (not untrusted-content)
(or (eq trusted-content :all)
(and buffer-file-name
...))))
At the same time one could consolidate the untrusted-content and
trusted-content variables as Eshel suggested?
(defun trusted-content-p ()
(and (not untrusted-content) ;; only for backward compat (deprecated)
(not (eq trusted-content :untrusted)) ;; replaces untrusted-content
(or (eq trusted-content :all)
(and buffer-file-name
...))))
Daniel
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 16 Dec 2024 09:32:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 16 04:32:03 2024 Received: from localhost ([127.0.0.1]:53521 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tN7SN-0005tK-3I for submit <at> debbugs.gnu.org; Mon, 16 Dec 2024 04:32:03 -0500 Received: from server.qxqx.de ([49.12.34.165]:40669 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1tN7SJ-0005se-LF for 74879 <at> debbugs.gnu.org; Mon, 16 Dec 2024 04:32:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1a1gJA1EN8Tp/aPr2dK7Mq8BBtvc3AwOIpDbfsCCh6Q=; b=dfFM8jI36djwj6horUkobqTQVJ jnvLsSh9UtLl0FcByTRvGQT3rEimndufZWcPfD70fPzKg4KUTkQdoxf2tcYHIuu9KPF7AJKrnmgBG HTSIgJBctpUGwokmbdk2PjdSoBSxEv+tQwBk4b+xvqd4+k+KsCxlvMfha8whlNbfGuRI=; From: Daniel Mendler <mail@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers In-Reply-To: <jwv5xnkshy1.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message of "Sun, 15 Dec 2024 17:41:59 -0500") References: <87ed29ixu8.fsf@HIDDEN> <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> <87msgw94fz.fsf@HIDDEN> <jwv5xnkshy1.fsf-monnier+emacs@HIDDEN> Date: Mon, 16 Dec 2024 10:29:41 +0100 Message-ID: <87v7vk562i.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74879 Cc: 74879 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Stefan Monnier <monnier@HIDDEN> writes: >> Given that the trust applies to the given buffer, setting `(setq-local >> trusted-files :all)' in this buffer feels odd as >> a recommended mechanism. > > I can live with that for now. > It's probably not much worse than > > (add-function :override (local 'trusted-content-function) #'always) > > [ BTW, I just renamed the var to `trusted-content`. ] I think it is not as good as a central configuration variable where I configure the trust for buffers or files. Now configuring trust is scattered across multiple major modes. My proposal was for a global hook variable which is consulted by `trusted-content-p' and then checks certain trust list for files or buffers. This way it is easier to check what we are trusting. >>> - Trust sucks, so we really should work on better solutions where we >>> don't need to rely on trust, such as running code in `bwrap` or other >>> kinds of sandboxes. >> I agree. But what about interactive scenarios like auto completion? > > I don't understand the question. I mean that not all of the scenarios can be run in some sandbox. If we cannot put all Capfs in a sandbox we could at least prevent auto completion entirely based on trust. >> I think trust checking might be helpful in all scenarios where there >> is a "low threshold" to invoking code execution or >> even unintentionally. > > Oh, you mean for code completion we don't want to incur the cost of > spawning a subprocess? Indeed that can be a reason to fallback to trust. The thought was rather that auto completion may be dangerous in general and since it is triggered with a low threshold one could prevent auto completion right away. I think you have a more fine-grained model in mind where certain macros are trusted and so on. > But note that in the "other kinds of sandboxes" I include things like > labeling macros with some indication about how they can be run safely, > so we can have a version of `elisp--safe-macroexpand-all` which does > something useful even if the buffer's content is not trusted. > >>> - I think we do want some kind of hook, with which we can have (for >>> instance) `emacs-lisp-mode` tell Emacs to trust the user init file, >>> the early-init file, the custom-file, and all the files in >>> `load-path`. >> >> You suggest a hook which is executed per buffer? This seems similar to >> my proposal of a `trusted-buffer-function` hook. > > Yes, that's exactly what I was referring to. > At first I was thinking of some kind of `trusted-buffer-functions` hook > used with `run-hook-with-args-until-success`, but I think you're right > that it's better to go with `trusted-buffer-function` so we can both add > and remove trust with it. My initial proposal was about a global `trusted-buffer-functions' hook but I may have not communicated this clearly enough. I have two problems with the buffer-local approach: 1. I find it difficult to check what we are trusting, since the trust settings are scattered over multiple files. 2. How can I configure certain buffers to be trusted? One could configure `trusted-content' at the time of buffer creation. Or is there a hook which you suggest to use? Right now it seems that the idea is to set `trusted-content` based on major modes? Daniel
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 16 Dec 2024 07:52:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 16 02:52:57 2024 Received: from localhost ([127.0.0.1]:53345 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tN5uN-0000my-Qk for submit <at> debbugs.gnu.org; Mon, 16 Dec 2024 02:52:57 -0500 Received: from mail.eshelyaron.com ([107.175.124.16]:46832 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <me@HIDDEN>) id 1tN5uH-0000mj-Jx for 74879 <at> debbugs.gnu.org; Mon, 16 Dec 2024 02:52:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1734335565; bh=SEK+rGyaVkpmXqTvJSkP8Xrwqz4uSZzdkTWXcyhJeP0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=pRhOHeCKlVePBf11cjElZ0sbZKeQleiYN2cG9XyapbbNBSXdyvLVV8bMrjuVrcSnQ DqdeLmvxNgOIfnP1kzIXIlcsCekabxgUSaW0pYLAWjyQY8OiXGHX+ktqhwfykkKres oVfYHi5rMi++eVv8naocYgDX0pcTf4w7+YC6UX5eWjSX6odkj/Ki3RAzFPUEdzwf2+ UTVp9at16OCjnn7T1XJ8VggOMgPcuDKVtjYEQWw1ZZ9QLWEpCVYmNiHvIxT1Z28+s5 0jHdEx4NWQ2xspXpGxmDQicpyT+Q+qE4xffPnBEiRlA4GQMWWAcmj1/yJtiqAUfq/W 8b+OqFS+r/neg== From: Eshel Yaron <me@HIDDEN> To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers In-Reply-To: <jwv5xnkshy1.fsf-monnier+emacs@HIDDEN> (Stefan Monnier via's message of "Sun, 15 Dec 2024 17:41:59 -0500") References: <87ed29ixu8.fsf@HIDDEN> <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> <87msgw94fz.fsf@HIDDEN> <jwv5xnkshy1.fsf-monnier+emacs@HIDDEN> Date: Mon, 16 Dec 2024 08:52:42 +0100 Message-ID: <m11py8rrn9.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74879 Cc: Daniel Mendler <mail@HIDDEN>, 74879 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hi, Thank you for your work on this mitigation! Stefan Monnier writes: > [ BTW, I just renamed the var to `trusted-content`. ] Note that now we have both trusted-content and untrusted-content, both security-related but with somewhat different meanings... It might be worth consolidating the two somehow to avoid confusion. Best, Eshel
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 16 Dec 2024 07:52:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 16 02:52:59 2024 Received: from localhost ([127.0.0.1]:53348 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tN5uU-0000nL-MO for submit <at> debbugs.gnu.org; Mon, 16 Dec 2024 02:52:58 -0500 Received: from lists.gnu.org ([209.51.188.17]:54664) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <me@HIDDEN>) id 1tN5uS-0000n4-Jk for submit <at> debbugs.gnu.org; Mon, 16 Dec 2024 02:52:57 -0500 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 <me@HIDDEN>) id 1tN5uN-0004BI-AP for bug-gnu-emacs@HIDDEN; Mon, 16 Dec 2024 02:52:51 -0500 Received: from mail.eshelyaron.com ([107.175.124.16] helo=eshelyaron.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <me@HIDDEN>) id 1tN5uI-00073p-Gn for bug-gnu-emacs@HIDDEN; Mon, 16 Dec 2024 02:52:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1734335565; bh=SEK+rGyaVkpmXqTvJSkP8Xrwqz4uSZzdkTWXcyhJeP0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=pRhOHeCKlVePBf11cjElZ0sbZKeQleiYN2cG9XyapbbNBSXdyvLVV8bMrjuVrcSnQ DqdeLmvxNgOIfnP1kzIXIlcsCekabxgUSaW0pYLAWjyQY8OiXGHX+ktqhwfykkKres oVfYHi5rMi++eVv8naocYgDX0pcTf4w7+YC6UX5eWjSX6odkj/Ki3RAzFPUEdzwf2+ UTVp9at16OCjnn7T1XJ8VggOMgPcuDKVtjYEQWw1ZZ9QLWEpCVYmNiHvIxT1Z28+s5 0jHdEx4NWQ2xspXpGxmDQicpyT+Q+qE4xffPnBEiRlA4GQMWWAcmj1/yJtiqAUfq/W 8b+OqFS+r/neg== From: Eshel Yaron <me@HIDDEN> To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers In-Reply-To: <jwv5xnkshy1.fsf-monnier+emacs@HIDDEN> (Stefan Monnier via's message of "Sun, 15 Dec 2024 17:41:59 -0500") References: <87ed29ixu8.fsf@HIDDEN> <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> <87msgw94fz.fsf@HIDDEN> <jwv5xnkshy1.fsf-monnier+emacs@HIDDEN> Date: Mon, 16 Dec 2024 08:52:42 +0100 Message-ID: <m11py8rrn9.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=107.175.124.16; envelope-from=me@HIDDEN; helo=eshelyaron.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: Daniel Mendler <mail@HIDDEN>, 74879 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.4 (--) Hi, Thank you for your work on this mitigation! Stefan Monnier writes: > [ BTW, I just renamed the var to `trusted-content`. ] Note that now we have both trusted-content and untrusted-content, both security-related but with somewhat different meanings... It might be worth consolidating the two somehow to avoid confusion. Best, Eshel
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.
Received: (at 74879) by debbugs.gnu.org; 15 Dec 2024 22:42:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 15 17:42:12 2024
Received: from localhost ([127.0.0.1]:52529 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tMxJS-0007u6-Me
for submit <at> debbugs.gnu.org; Sun, 15 Dec 2024 17:42:11 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16013)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1tMxJQ-0007tt-IU
for 74879 <at> debbugs.gnu.org; Sun, 15 Dec 2024 17:42:09 -0500
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id F0D941000EF;
Sun, 15 Dec 2024 17:42:01 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1734302521;
bh=6G1LXlX2WCkw0+9PRJwlY5gYnnFdTkLkxTUvNvck0BA=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=cuNpDRk+GJrCum7prI1It9hRXaQTYr1lLX0EzNddfAETWXS1080WupR5YBBeOFWWs
fA1abqqEVvWteteQXjc6rOFcTU6GSvLngtyLaiLw2REvFU7C0irjrm+B9FVU+Omt2d
DGguBUqUOZFWG8145fhq08Um6TYy2RY2kapsBu4NDMT9d0XhCUk8eD9Map1UpD9rAq
K/kz2hEdd4yV0x1AwN06clPV/hyv/GebchypwsRCIi9Jet0QqrWjKv3fuqvu/A081v
BK5ntfRJKSJT/MRPHjWjUt13D78Su7e2dDFbn+RvkrIls3xvTxs2Z4E/pbIHb+CPBA
SmmsgBL5mHsLg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 041ED1000BD;
Sun, 15 Dec 2024 17:42:01 -0500 (EST)
Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 916BA120504;
Sun, 15 Dec 2024 17:42:00 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Daniel Mendler <mail@HIDDEN>
Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot
be used for non-file buffers
In-Reply-To: <87msgw94fz.fsf@HIDDEN> (Daniel Mendler's message of
"Sun, 15 Dec 2024 19:38:56 +0100")
Message-ID: <jwv5xnkshy1.fsf-monnier+emacs@HIDDEN>
References: <87ed29ixu8.fsf@HIDDEN>
<jwvikrlukf7.fsf-monnier+emacs@HIDDEN>
<87msgw94fz.fsf@HIDDEN>
Date: Sun, 15 Dec 2024 17:41:59 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.031 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 74879
Cc: 74879 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> - The current setup is a kind of "minimal" change for Emacs-30 because
>> it's late in the pretest, so as much as possible we should separate
>> the discussion into what's a simple enough solution for Emacs-30 and
>> what we should use in the longer term.
>
> Agree. As I suggested a simple trusted-buffer-function hook may be the
> simplest solution, which is also not limiting and allows us to mark
> various buffers as trusted.
>
>> - You should be able to get fully-featured Flymake in *scratch*
>> with (setq-local trusted-files :all).
>> Maybe we should do that when we setup *scratch*?
>> Which other non-file buffers would need that? The minibuffer?
>
> Given that the trust applies to the given buffer, setting `(setq-local
> trusted-files :all)' in this buffer feels odd as
> a recommended mechanism.
I can live with that for now.
It's probably not much worse than
(add-function :override (local 'trusted-content-function) #'always)
[ BTW, I just renamed the var to `trusted-content`. ]
> Even more so since the variable is marked as risky local.
"Risky local" refers to file/dir-local settings, not
buffer-local settings.
>> - Trust sucks, so we really should work on better solutions where we
>> don't need to rely on trust, such as running code in `bwrap` or other
>> kinds of sandboxes.
> I agree. But what about interactive scenarios like auto completion?
I don't understand the question.
> There we may be limited to trust, even if we want sandboxing in other
> scenarios.
Why? What's different?
> I think trust checking might be helpful in all scenarios where there
> is a "low threshold" to invoking code execution or
> even unintentionally.
Oh, you mean for code completion we don't want to incur the cost of
spawning a subprocess? Indeed that can be a reason to fallback to trust.
But note that in the "other kinds of sandboxes" I include things like
labeling macros with some indication about how they can be run safely,
so we can have a version of `elisp--safe-macroexpand-all` which does
something useful even if the buffer's content is not trusted.
>> - I think we do want some kind of hook, with which we can have (for
>> instance) `emacs-lisp-mode` tell Emacs to trust the user init file,
>> the early-init file, the custom-file, and all the files in
>> `load-path`.
>
> You suggest a hook which is executed per buffer? This seems similar to
> my proposal of a `trusted-buffer-function` hook.
Yes, that's exactly what I was referring to.
At first I was thinking of some kind of `trusted-buffer-functions` hook
used with `run-hook-with-args-until-success`, but I think you're right
that it's better to go with `trusted-buffer-function` so we can both add
and remove trust with it.
Stefan
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.
Received: (at 74879) by debbugs.gnu.org; 15 Dec 2024 22:24:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 15 17:24:41 2024
Received: from localhost ([127.0.0.1]:52504 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tMx2X-00071s-6z
for submit <at> debbugs.gnu.org; Sun, 15 Dec 2024 17:24:41 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38492)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1tMx2V-00071d-D9
for 74879 <at> debbugs.gnu.org; Sun, 15 Dec 2024 17:24:39 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C39E8440F87;
Sun, 15 Dec 2024 17:24:33 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1734301472;
bh=pw72ez4FuURNCGM0UnpbmRrljUwFnUm9opJ3xndRjbU=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=dn9NqaCKqDve9ierCM3Nl3Ku0G8aPy4pNa0LJdEuq4UOMyZrMP1d8GZy4Jx1Ak5j/
AhFN+TrjUSQquIlPbvGuAJU+PMQGCrfpWoqpuzZG4/CDsbKhWf5Op/C/MMBU4e5OvW
MbASHMKu13qBZIVqdhoEbcvVscXH1gkUa3TBFQo3/+BeP1ECj1bQOynCCXkW5oERS+
QhtGyccrOK8n7Jo+0Q3UNG1yxGtZ0jUM8cu/ke7p+nIrCiDNC/c2+pB3feao++MAjl
8pl0q1RocFVCvNZFE1HNtQ8zc7yGb7uuTl7T/tIFUVzs/Gh7u7B/S1Z+a3movUq3Ym
1+BhC/1Y9Yodw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D2EF4440F5F;
Sun, 15 Dec 2024 17:24:32 -0500 (EST)
Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A5C7A120490;
Sun, 15 Dec 2024 17:24:32 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Stefan Kangas <stefankangas@HIDDEN>
Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot
be used for non-file buffers
In-Reply-To: <CADwFkmmzTRBXETT5vJWbuJ544-TEf7N-Ev4xjF-2LS9aTYVB3Q@HIDDEN>
(Stefan Kangas's message of "Sun, 15 Dec 2024 14:30:09 +0000")
Message-ID: <jwvbjxcshyk.fsf-monnier+emacs@HIDDEN>
References: <87ed29ixu8.fsf@HIDDEN>
<jwvikrlukf7.fsf-monnier+emacs@HIDDEN>
<CADwFkmmzTRBXETT5vJWbuJ544-TEf7N-Ev4xjF-2LS9aTYVB3Q@HIDDEN>
Date: Sun, 15 Dec 2024 17:24:32 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.009 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 74879
Cc: Daniel Mendler <mail@HIDDEN>, 74879 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> - You should be able to get fully-featured Flymake in *scratch*
>> with (setq-local trusted-files :all).
>> Maybe we should do that when we setup *scratch*?
>> Which other non-file buffers would need that? The minibuffer?
>
> ielm comes to mind.
Thanks (fixed in `emacs-30`).
Stefan
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 15 Dec 2024 18:41:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 15 13:41:20 2024 Received: from localhost ([127.0.0.1]:52042 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tMtYN-0004Yw-04 for submit <at> debbugs.gnu.org; Sun, 15 Dec 2024 13:41:19 -0500 Received: from server.qxqx.de ([49.12.34.165]:45141 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1tMtYK-0004Yb-TW for 74879 <at> debbugs.gnu.org; Sun, 15 Dec 2024 13:41:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Q7OLyG5AdoTM4gDM2TRKSNbKLflLZzL1oGpcgRAQSps=; b=JA+HdDDdkmIj9fnz3RFjvHGTzi LnjVYWEmc/0DYmhwpWQCk4HU/mxqsJIuGzCqKg66rBuy3JIDWdsC+MVvlVB0mAzib5YC7ABctKZT0 ao4z8Q+RzI0caSWTUWp3UT6vB36xWkZJm2MO6YQKyhjjhEeRHXpP29pDrAFUbjkQW9zI=; From: Daniel Mendler <mail@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers In-Reply-To: <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message of "Sun, 15 Dec 2024 09:03:18 -0500") References: <87ed29ixu8.fsf@HIDDEN> <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> Date: Sun, 15 Dec 2024 19:38:56 +0100 Message-ID: <87msgw94fz.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74879 Cc: 74879 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Stefan Monnier <monnier@HIDDEN> writes: >> Thank you for the recent addition of `trusted-content-p'. Is there a >> possibility to use `trusted-content-p' in buffers which are not backed >> by a file? I use Flymake in *scratch* or similar buffers and it seems >> that this won't continue to work given that `trusted-content-p' needs a >> `buffer-file-truename'. > > Good question. > We don't really have a good answer yet, AFAIK, in large part because we > don't have enough experience with it. > Off the top of my head, here are some elements relevant to this > discussion, in random order: > > - The current setup is a kind of "minimal" change for Emacs-30 because > it's late in the pretest, so as much as possible we should separate > the discussion into what's a simple enough solution for Emacs-30 and > what we should use in the longer term. Agree. As I suggested a simple trusted-buffer-function hook may be the simplest solution, which is also not limiting and allows us to mark various buffers as trusted. > - You should be able to get fully-featured Flymake in *scratch* > with (setq-local trusted-files :all). > Maybe we should do that when we setup *scratch*? > Which other non-file buffers would need that? The minibuffer? Given that the trust applies to the given buffer, setting `(setq-local trusted-files :all)' in this buffer feels odd as a recommended mechanism. Even more so since the variable is marked as risky local. > - Trust sucks, so we really should work on better solutions where we > don't need to rely on trust, such as running code in `bwrap` or other > kinds of sandboxes. I agree. But what about interactive scenarios like auto completion? There we may be limited to trust, even if we want sandboxing in other scenarios. I think trust checking might be helpful in all scenarios where there is a "low threshold" to invoking code execution or even unintentionally. > - I think we do want some kind of hook, with which we can have (for > instance) `emacs-lisp-mode` tell Emacs to trust the user init file, > the early-init file, the custom-file, and all the files in > `load-path`. You suggest a hook which is executed per buffer? This seems similar to my proposal of a trusted-buffer-function hook. Daniel
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 15 Dec 2024 15:17:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 15 10:17:18 2024 Received: from localhost ([127.0.0.1]:51610 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tMqMw-00037f-0f for submit <at> debbugs.gnu.org; Sun, 15 Dec 2024 10:17:18 -0500 Received: from mail-ed1-f54.google.com ([209.85.208.54]:46140) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tMqMu-00037X-8S for 74879 <at> debbugs.gnu.org; Sun, 15 Dec 2024 10:17:16 -0500 Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-5ceb03aadb1so4564694a12.0 for <74879 <at> debbugs.gnu.org>; Sun, 15 Dec 2024 07:17:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734275775; x=1734880575; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=b80jt5cNbRg0wuCMONuyZ4q/me+i287O3Zib3ec2fDc=; b=TI7WYO3OYhbHI/vF09dZhuvgyzH5yQiODxnBd5ccuqy62JVc+XTMtBuONK1m8p5nvU nsrkxH0MHllkTs+iyXbajKimUZ0XWzXBIjopXDUmRx6sQS/Be/+oPq7IA6EJJAZh4R7f WdEEHLbV07RX8fcKIg4OXeQvDqVw5KKYpQCwmFApGiTSoc0iMJpnLp5lGGV8X0uJ4vJ0 NplrPDmBc8PMFd9kuMj25sKqWbiylmrr2CH0NZ+KOzbN25NNhs5Nt3WcPwEjtFvlfz8o YFPOx7aGqAZLg4LoVwJpWv7hwLVsPII/uMtaZb7VJoRQOAxnIS6/MOoeXcJ/QMIAdLoY LITw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734275775; x=1734880575; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=b80jt5cNbRg0wuCMONuyZ4q/me+i287O3Zib3ec2fDc=; b=F2QFYiPEhP9lkqk5x6zA6YYHhYW5oEO1dfOKcLhnCCDD7rmM6x2uH+igwfEIXD3Z8O IHSm0smHBQStGxAhdMu/YLuJ2y0qWsTpTj3MD6GugE4DNRT5Ew7IWV3t2orLyEZ4TzHM FJNU69DllYYtqcpJ2VgiYP1levdPmQUU5wY6B0/GJLzsmd4UcVQToItiDuD2qO3S5gNv xQXbzZdW6kl/84gEpVEE20B/QqB0KNcpLozP639e2S3JO0Q8PumLAJDGPYt7bz/+Thw6 4vMS7PCdNqmTkcScwvfMgw+rZzMInKYOz0QyFDCYKPiKeIz9YQ6wkN6lwwdfn38Gb54X 0lug== X-Forwarded-Encrypted: i=1; AJvYcCVsVo+UFETm/eSW8etUiLHSrzPfdsbD4zq5oKZnJeNZdk7FUYTXHyrl+QCbidMDheFbKTU8vA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyWIuHDkpByTbHZIbkxDuJ3pyki46OQwn7j90x3di1OkDlwPpab CamXgAFBZrJXS4bwGfHxf5DPcg9hhYHf+Db1F0HxJvX2fvZ4nyRkZ1gR9w== X-Gm-Gg: ASbGncsQ5rJYMO5fk+nPdPLXR0JTCKqcBM6/WguyFeRdd3N7t+J7RBRnk8AnHMeZvbE kOJnLAJ0OzAGGfR9PYtYM7ukR0ITcqD0V4qeHIeh0zSQKM7JlN8tF3n199XhqU9xIQ/caHcLayF rKJ4qnr5dyLDZnHj83NISwb80+uAGOBLh2UWQm3uRJQU9vStXiKIj92dTSEvCXiBtdjrTBPQFfW kJLA9tWsmHLr639/Grsju91Jog2UQiNB2L8SxyXFA1ylWslgN5lAvGbDBE4h6p2sPh5YicECpj/ zv1Gm1L9oTWfgS0fOl7GhElrt2fDn/fEIiPxaMaLFfFgoUJC+4yOukgedaP+8b6fVg== X-Google-Smtp-Source: AGHT+IGKqTLopyfpnhO1CrD4YZXWZGwp0qEBSyfQqPuHO2ilywqzBNTPpx5nxiV+/ccYin7ST8elYg== X-Received: by 2002:a05:6402:3813:b0:5d0:849c:71c3 with SMTP id 4fb4d7f45d1cf-5d63c15ec5fmr8584229a12.0.1734275774874; Sun, 15 Dec 2024 07:16:14 -0800 (PST) Received: from pro2 (p200300e0b7208800845360bbbfb3451f.dip0.t-ipconnect.de. [2003:e0:b720:8800:8453:60bb:bfb3:451f]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d652ab5082sm2132691a12.4.2024.12.15.07.16.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Dec 2024 07:16:13 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers In-Reply-To: <jwvr069t26j.fsf-monnier+emacs@HIDDEN> (Stefan Monnier via's message of "Sun, 15 Dec 2024 10:10:05 -0500") References: <87ed29ixu8.fsf@HIDDEN> <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> <m2y10hf12p.fsf@HIDDEN> <jwvr069t26j.fsf-monnier+emacs@HIDDEN> Date: Sun, 15 Dec 2024 16:16:12 +0100 Message-ID: <m2r069f03n.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74879 Cc: Daniel Mendler <mail@HIDDEN>, 74879 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> writes: >> Random thought: >> >> - What if a user pastes text from a untrusted source to a trusted buffer? >> >> - Is taint checking relevant in this context? >> >> https://en.wikipedia.org/wiki/Taint_checking > > I'll just repeat that trust sucks. > It's a last recourse and we should work to implement better solutions. Sure, I didn't mean it as a critique on what's there.
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 15 Dec 2024 15:16:33 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 15 10:16:32 2024 Received: from localhost ([127.0.0.1]:51606 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tMqMC-000366-FB for submit <at> debbugs.gnu.org; Sun, 15 Dec 2024 10:16:32 -0500 Received: from lists.gnu.org ([209.51.188.17]:40784) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tMqM6-00035u-US for submit <at> debbugs.gnu.org; Sun, 15 Dec 2024 10:16:28 -0500 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 <gerd.moellmann@HIDDEN>) id 1tMqM1-0001kU-Tl for bug-gnu-emacs@HIDDEN; Sun, 15 Dec 2024 10:16:25 -0500 Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <gerd.moellmann@HIDDEN>) id 1tMqLz-0004zF-UO for bug-gnu-emacs@HIDDEN; Sun, 15 Dec 2024 10:16:21 -0500 Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-5d3d143376dso4793003a12.3 for <bug-gnu-emacs@HIDDEN>; Sun, 15 Dec 2024 07:16:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734275775; x=1734880575; darn=gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=b80jt5cNbRg0wuCMONuyZ4q/me+i287O3Zib3ec2fDc=; b=c0gXI6oVDRxNKDM084/kLfBOI+jj0WWcyiZKUgn43OgfGuFEczkP8ovMmxlWf7e0jl MX5JwDCcBn5uj8RLBSGrt/bbG/u1h0bL2WjzV8kiBexxHGeZeX2EWVJ8sThYpfzZrI4K Hml2nWdv8aZhAmJFxIbwx5d2lsCy0ZkupvR/zrbdPlK6h60YVA009DbVx0fgxMJXYBiA AVcu8spage6DloWCkAtE8EWtQZpQ+8KvavTwCyItiUqxrNbGB05wDOq7BHR/b1OVQ25n OYzOoCwU3B2RSz773bYn9c8rlo8eqpPsJeXSQoonaNblHBHp0eidIVhwMVMrojK3iwbL yy0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734275775; x=1734880575; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=b80jt5cNbRg0wuCMONuyZ4q/me+i287O3Zib3ec2fDc=; b=p53b3qnmMOZFGWB/Ypwptef0Q1mqAACm8C+MaUdvb3jWwmbqAVgOYG3oxbWFRLh43K 19ZkzzJXccf8AQni8KKlkAZjpvWuXSkLvz4UKd1itCVAFv10LmQzYnxiylXbTCxprQ7q walW1xBkGYKv7e6i2CphW3SaU7FydX905ijbkkFFGWB7yBdd3QmwpjK22bNIEGhow8DG IN7sKySVdW/tbVVhTBHtUU93gaMfCsArMnUAhi7HdLNNQYJflXMc/eEV/ruOmpklewDW nL4oy9Koz3aYoJq2ItyRt2QvHVfWKwu+rcLcLpLTF8aG787Jjtaa1yPR4pF/qSJuY+Qj O8CQ== X-Gm-Message-State: AOJu0Yy9EP/o/35BTuw3ZjIEz7NWX7tVGTYTBGzL6ccbp+NiiLcpZDZo +WH/TW/9lorIujCyQAth+29OxqJTHpcEgLFHsmNmhaHrF0GiSQOa X-Gm-Gg: ASbGnctiy7bTCFwoikvVLAaXbrJldFRE/jEIwP3KVM0dR1zJMlNBDwaQsAYAqJKXcxj mdggFrSLhB+tsDLI9+QvGPCdkStgmKMASQt0frSZi+7aWVTyFuJBk++5te5RMPKKwnSuudk92Ov cUjBfkC9mtLACOrC4bUVLyv701rWQAy3qXyyKbt9jaqg6B40qdUGTrERxxCwJILpFi71cihmMda 9G4/NKQmEIQ1ChOkpXs+ZCHHEROWum00kJZ8tVL76YqkuHYvm4y8vZTlCHWBNku4qJlXJPVbOak gSv3O2qCam0GzNB+xvc2mj/aBjgLAJ/OZ9C2WRm66r8Qhwmvt5m+prfjKsdt0+/OiQ== X-Google-Smtp-Source: AGHT+IGKqTLopyfpnhO1CrD4YZXWZGwp0qEBSyfQqPuHO2ilywqzBNTPpx5nxiV+/ccYin7ST8elYg== X-Received: by 2002:a05:6402:3813:b0:5d0:849c:71c3 with SMTP id 4fb4d7f45d1cf-5d63c15ec5fmr8584229a12.0.1734275774874; Sun, 15 Dec 2024 07:16:14 -0800 (PST) Received: from pro2 (p200300e0b7208800845360bbbfb3451f.dip0.t-ipconnect.de. [2003:e0:b720:8800:8453:60bb:bfb3:451f]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d652ab5082sm2132691a12.4.2024.12.15.07.16.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Dec 2024 07:16:13 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers In-Reply-To: <jwvr069t26j.fsf-monnier+emacs@HIDDEN> (Stefan Monnier via's message of "Sun, 15 Dec 2024 10:10:05 -0500") References: <87ed29ixu8.fsf@HIDDEN> <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> <m2y10hf12p.fsf@HIDDEN> <jwvr069t26j.fsf-monnier+emacs@HIDDEN> Date: Sun, 15 Dec 2024 16:16:12 +0100 Message-ID: <m2r069f03n.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::530; envelope-from=gerd.moellmann@HIDDEN; helo=mail-ed1-x530.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: Daniel Mendler <mail@HIDDEN>, 74879 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> writes: >> Random thought: >> >> - What if a user pastes text from a untrusted source to a trusted buffer? >> >> - Is taint checking relevant in this context? >> >> https://en.wikipedia.org/wiki/Taint_checking > > I'll just repeat that trust sucks. > It's a last recourse and we should work to implement better solutions. Sure, I didn't mean it as a critique on what's there.
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.
Received: (at 74879) by debbugs.gnu.org; 15 Dec 2024 15:10:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 15 10:10:17 2024
Received: from localhost ([127.0.0.1]:51598 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tMqG9-0002pb-GI
for submit <at> debbugs.gnu.org; Sun, 15 Dec 2024 10:10:17 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62280)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1tMqG6-0002mk-0K
for 74879 <at> debbugs.gnu.org; Sun, 15 Dec 2024 10:10:15 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E40404409CD;
Sun, 15 Dec 2024 10:10:07 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1734275406;
bh=czGdJy/uD1u60cPYQPbuZDr3Eg6fiIjeT1Uq9pdDE9Y=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=gg1NuTAvwqdKV3RjI6Bf7QxEiCvzjuE3lKic/awb0kEtDtn1/4rWAXQr0sz3zARea
f4tYQii3SzengOUDAtXNKwYkx3BXNgZZ2NDLpq1UJ7PS08KtHYv63MnE2dqEQIIZ5n
bYCWGksQzRZDkkNgHbKkMdDTQJrrer6er86pXvxhazi9/dVgsoqqroeImQJ42kam6y
Fw8Tmmj3mlbWnLEXeAsOiJvzVTBJS/nB7x4u7mPMVSxqSZC0iq0xpndCQTgcwDqlzM
R7M7KdcRoyMDqiZKzdIgIeXQeKsd/0qhe3+V18xhSel+cdtVItbCTrUuSBFYylYvxO
iG2hc4HBTq67w==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 83E09440922;
Sun, 15 Dec 2024 10:10:06 -0500 (EST)
Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5171F12029E;
Sun, 15 Dec 2024 10:10:06 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Gerd =?windows-1252?Q?M=F6llmann?= <gerd.moellmann@HIDDEN>
Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot
be used for non-file buffers
In-Reply-To: <m2y10hf12p.fsf@HIDDEN> ("Gerd =?windows-1252?Q?M=F6llmann?=
=?windows-1252?Q?=22's?= message of "Sun, 15
Dec 2024 15:55:10 +0100")
Message-ID: <jwvr069t26j.fsf-monnier+emacs@HIDDEN>
References: <87ed29ixu8.fsf@HIDDEN>
<jwvikrlukf7.fsf-monnier+emacs@HIDDEN> <m2y10hf12p.fsf@HIDDEN>
Date: Sun, 15 Dec 2024 10:10:05 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.009 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 74879
Cc: Daniel Mendler <mail@HIDDEN>, 74879 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Random thought:
>
> - What if a user pastes text from a untrusted source to a trusted buffer?
>
> - Is taint checking relevant in this context?
>
> https://en.wikipedia.org/wiki/Taint_checking
I'll just repeat that trust sucks.
It's a last recourse and we should work to implement better solutions.
Stefan
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.
Received: (at 74879) by debbugs.gnu.org; 15 Dec 2024 14:56:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 15 09:56:17 2024
Received: from localhost ([127.0.0.1]:51567 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tMq2b-0001tY-Gj
for submit <at> debbugs.gnu.org; Sun, 15 Dec 2024 09:56:17 -0500
Received: from mail-ej1-f41.google.com ([209.85.218.41]:48267)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <gerd.moellmann@HIDDEN>) id 1tMq2Y-0001tQ-IC
for 74879 <at> debbugs.gnu.org; Sun, 15 Dec 2024 09:56:16 -0500
Received: by mail-ej1-f41.google.com with SMTP id
a640c23a62f3a-aa66ead88b3so616420166b.0
for <74879 <at> debbugs.gnu.org>; Sun, 15 Dec 2024 06:56:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1734274513; x=1734879313; darn=debbugs.gnu.org;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
bh=ndrpSuoisH2gZqa0Urd67QYF0zw+ztyktGFoVc7DU8A=;
b=gWKiKukocGVfr03DVP8SLhknqc7ZS2ElB9pmXitDf6zw+zk51HoSlGIqHfdZpS9SyP
IIxfLTfy+kX/abXO7S5vFO6N39tNwvhjAQqfhrDkFG3cGlrDVRs91Fg7ZuBURSl9DK9G
oMmsfYRhtkq6omvuUsi4z8ikbj59o2WEQ/RN+9nnvFJkAcCdXK5Wtno88PxEVETUKoBh
1Nr9SztRJeuZGTkPUQw/JU7VdBvNYKabminH9G8P8s13RpLx356SSpaq6gMOFBLuptFd
UHFW/RUGZvySEhYpllt+wVDNAq9Ow9KMNNZY9ML+eFgmGHZaoEJmwSimxtRsb6tl27Ed
Wrow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1734274513; x=1734879313;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=ndrpSuoisH2gZqa0Urd67QYF0zw+ztyktGFoVc7DU8A=;
b=BAOOU7zm4+vY7oeAZXJquAdg4nX4jmdj/VbLp7xua8et/vX7Tup9Yn5dS3C4/YuFho
9NToHQCNchHigRka8Mj9ykRRV9KRODp9vnkvJe9iXDLnwGJl2RVvBKNMOPX/PhKP85jp
RmIv0jYlLLZIjvXl4imBVfwdWT8DusJJuXOOO/uhIrbV9yvxNV5kou3sJ1BUbV8egGb7
APUlUkhSk43aaH7aaR+74hYx1EotOlhXywgpXgmBQmvYotm6+OhRFuo8N6PhTX9pUs7z
dbXiZO70lvBYrsz0JMmc80RyC1sJpDXWd5xOKVaRhwbik/CU7RCoMVZGdMjRY2F5j4TA
cauQ==
X-Forwarded-Encrypted: i=1;
AJvYcCUp2S+s1pDcrpbPIeUIa7+0GaAVWW9vX0xaahk8TA19ttLuC3Yn291S4rO7GPAXOsm2cQulXQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YwZ5EQ4a3YWCOYGcedkzAhjuyeHOqo83Kyu7GCzIpDCE9oYb4Zs
lcxym1uWrvYyKZjMskVmnJrjhMAuBCsIkoqZ6Z05mJwIxfMxvDEaaxhCzQ==
X-Gm-Gg: ASbGncsPDwi/hTQ6JM3Pp3cq7uk5QM1yG/RsizpvfXGn7C4TIGWhrVLUnvfokSpTgQ9
e5yoEdPUtARFREW6Kgt60e6hbzgR7CIdDOkwAvVi09qouAYbFHC+x8N/0NeO/CusvfqF9AX/MZD
nXk3hHQ4tm2vDHeArdlbD0kaYYk50L35HvUgT2yP28kjWBLIpjMzCZEFQeZPbpg/aPT2BhzXR3A
7BOPQSr4pNrc6bhzV9oExuz/09UTRih+2AepT1MUwOoSHxPqjmjJdu1F80vti3vAKauhf9IDcwV
tFyZXFvGLxemXCcVvY29JWoGs2q1zI584LfClwwEhm3FPGa11/4wslSWe9AL0OMFZw==
X-Google-Smtp-Source: AGHT+IEqa3HEuv7U/H+/lvfdlSYKkm0TJih/tDyHXpYkNJ1RSVjMn5KDn/MfAJl969ArbJQMZyezSQ==
X-Received: by 2002:a17:906:31c1:b0:aa6:8935:ae71 with SMTP id
a640c23a62f3a-aab778c1e2dmr864719666b.12.1734274513253;
Sun, 15 Dec 2024 06:55:13 -0800 (PST)
Received: from pro2 (p200300e0b7208800845360bbbfb3451f.dip0.t-ipconnect.de.
[2003:e0:b720:8800:8453:60bb:bfb3:451f])
by smtp.gmail.com with ESMTPSA id
a640c23a62f3a-aab96067edbsm216909066b.49.2024.12.15.06.55.11
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sun, 15 Dec 2024 06:55:12 -0800 (PST)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot
be used for non-file buffers
In-Reply-To: <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
of "Sun, 15 Dec 2024 09:03:18 -0500")
References: <87ed29ixu8.fsf@HIDDEN>
<jwvikrlukf7.fsf-monnier+emacs@HIDDEN>
Date: Sun, 15 Dec 2024 15:55:10 +0100
Message-ID: <m2y10hf12p.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 74879
Cc: Daniel Mendler <mail@HIDDEN>, 74879 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Stefan Monnier <monnier@HIDDEN> writes:
>> Thank you for the recent addition of `trusted-content-p'. Is there a
>> possibility to use `trusted-content-p' in buffers which are not backed
>> by a file? I use Flymake in *scratch* or similar buffers and it seems
>> that this won't continue to work given that `trusted-content-p' needs a
>> `buffer-file-truename'.
>
> Good question.
> We don't really have a good answer yet, AFAIK, in large part because we
> don't have enough experience with it.
> Off the top of my head, here are some elements relevant to this
> discussion, in random order:
>
> - The current setup is a kind of "minimal" change for Emacs-30 because
> it's late in the pretest, so as much as possible we should separate
> the discussion into what's a simple enough solution for Emacs-30 and
> what we should use in the longer term.
>
> - You should be able to get fully-featured Flymake in *scratch*
> with (setq-local trusted-files :all).
> Maybe we should do that when we setup *scratch*?
> Which other non-file buffers would need that? The minibuffer?
>
> - Trust sucks, so we really should work on better solutions where we
> don't need to rely on trust, such as running code in `bwrap` or other
> kinds of sandboxes.
>
> - I think we do want some kind of hook, with which we can have (for
> instance) `emacs-lisp-mode` tell Emacs to trust the user init file,
> the early-init file, the custom-file, and all the files in
> `load-path`.
>
> - There is overlap with `safe-local-variable-directories`,
> `enable-local-variables` and it would be nice to consolidate (which
> can require delicate timing if we want the major mode to inform which
> content to trust).
>
Random thought:
- What if a user pastes text from a untrusted source to a trusted buffer?
- Is taint checking relevant in this context?
https://en.wikipedia.org/wiki/Taint_checking
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 15 Dec 2024 14:31:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 15 09:31:25 2024 Received: from localhost ([127.0.0.1]:50031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tMpeW-0000Ny-Ou for submit <at> debbugs.gnu.org; Sun, 15 Dec 2024 09:31:25 -0500 Received: from mail-ed1-f45.google.com ([209.85.208.45]:56339) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1tMpeN-0000NP-Ri for 74879 <at> debbugs.gnu.org; Sun, 15 Dec 2024 09:31:20 -0500 Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-5d3f65844deso5376787a12.0 for <74879 <at> debbugs.gnu.org>; Sun, 15 Dec 2024 06:31:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734273010; x=1734877810; 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=NQlgiNSqcJ4iA7xtvOYDJrTKfMb2UFA05Rp+5r/gTdU=; b=OLdrKXYLwypl8cl2caAKl1mgObLzzRigMWpw+6+pzsFbJ5Bk1ROCXKFKh2nVDHv4M0 M5UHHVf/KZqQvzp/5r2MJCo218ClYv3LiGWGccBQOZ9NeOgwnGXxgD5vGohO2K0ClN8r WecIVKe8C3I9uO+tN5NiV4DrC6WEARxTC4ydO186NgxbKba5xyQNLUEGhTZj7eLqggQt pvL0+5UdZ2RbN5FMaoBDqSWrvZN8vC4uEIHr+5r4UNMXVI/vRIHTvt81h/i104DB/eMJ Yx1wHqnfVfM/nP4JwBufIgywB7JnqsJSKBRWSy6y12Fi7H537nFqzIjhzVVwuQcAjkz4 X3Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734273010; x=1734877810; 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=NQlgiNSqcJ4iA7xtvOYDJrTKfMb2UFA05Rp+5r/gTdU=; b=g5eEd8aRaH/C2+hvqsatfIddWaP2HYK+BKtTF6wGokQq17fwBO8KrPk3Fxq8iwPaWV ukWh2lcsbkeYn6mCk8SUBf8a6luxlGv7+NkHejsHVUPRUtPje2t7MajexQqBb0LRznAf RaVCgBOfRN1Ds6zGeOpiKq6YE0sUOnhdSgGIpiffO7EfMYosKMK4/TYkz4dW8qmlf5T3 Enbn15K8R+Snou6kS6NMXZTWKzhd20xRw4nbPjMaxR0sWBwooFj5owWr6jSSYMs24+93 m84lU03RPP+KfAafHnf2059LewfGuVfSfUS7MZp39se/mdMkNa2aeX3anoUeGRwkuzkK AOPw== X-Gm-Message-State: AOJu0YxbT03zlwPUhWGL8dRECXHz28FJsJafAm72/9WhGOkfrobSlm6M O+mq8J/qamDvxBMa9Hmv9ttq1SO28SRyDSx6NlVAx0rJP0YBhOkno1z77pdb6VcjTKtHgYRvPyz aUMdghs8ax+PShZERkm8hGJ7HPe0= X-Gm-Gg: ASbGnctG20WW94XYNN3FYh3YmLSdg8jWvha+KSol1/EVgSRRPRWmR4HbVEr31IL+TQ4 3xeHBdIoSRO3DjHiKCOj/gd5NDizQDmP64eByJG8= X-Google-Smtp-Source: AGHT+IGwDVOHjM+jQO7z661GMeQpwP+qm5JQTc5rz6P34PHni0Sx9/M9y53/3eGJAvj1nHXycekTqlE0bcfGVIvburE= X-Received: by 2002:a05:6402:348b:b0:5d0:8197:7ab3 with SMTP id 4fb4d7f45d1cf-5d63c2e5275mr8366699a12.3.1734273009909; Sun, 15 Dec 2024 06:30:09 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sun, 15 Dec 2024 14:30:09 +0000 From: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> References: <87ed29ixu8.fsf@HIDDEN> <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> MIME-Version: 1.0 Date: Sun, 15 Dec 2024 14:30:09 +0000 Message-ID: <CADwFkmmzTRBXETT5vJWbuJ544-TEf7N-Ev4xjF-2LS9aTYVB3Q@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers To: Stefan Monnier <monnier@HIDDEN>, Daniel Mendler <mail@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74879 Cc: 74879 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> writes: > - You should be able to get fully-featured Flymake in *scratch* > with (setq-local trusted-files :all). > Maybe we should do that when we setup *scratch*? > Which other non-file buffers would need that? The minibuffer? ielm comes to mind.
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 15 Dec 2024 14:03:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 15 09:03:30 2024 Received: from localhost ([127.0.0.1]:49986 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tMpDV-0007Jt-MW for submit <at> debbugs.gnu.org; Sun, 15 Dec 2024 09:03:30 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:25734) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1tMpDS-0007Jg-PS for 74879 <at> debbugs.gnu.org; Sun, 15 Dec 2024 09:03:27 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id AC4AE808F9; Sun, 15 Dec 2024 09:03:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1734271399; bh=ruNGKyR8aDUVC/CDM1EKM60YaloBcJx9SMXf1NmLCUc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=NMEzHVNcqBykTjsvVNuHXnOMvAFy+H5gMxnzjEkfTKw8Hi0fms7dRPfcR+3CR1n/K S4AUY2OpND4lHU8r6/Y+wR67QGT1VVazS/mm0HicpaEkNrEl0Nmr0xGdhjSm9lKR6W erhZ2z5/uJ8884+K0lEl4qxYpcPNWir4f2Eo+/9Q0zDUA+gWyCE3KFsL0TfitUf1L6 yp6FMY0h/f8HI8zpm+pC+Vi6HimSjGBNrRRBuT9eOsrAylQ0cVdBRGw++Ot/lJJolg 7WBkv5zPxgir/4ktiwOWVR/2VFsXkSz/GRkRIkM3XHtScMT11BFcI8MxdlLNckApts zylZwbhR8ZxRw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D75E28079A; Sun, 15 Dec 2024 09:03:19 -0500 (EST) Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B25D91204C4; Sun, 15 Dec 2024 09:03:19 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> To: Daniel Mendler <mail@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers In-Reply-To: <87ed29ixu8.fsf@HIDDEN> (Daniel Mendler's message of "Sun, 15 Dec 2024 01:39:11 +0100") Message-ID: <jwvikrlukf7.fsf-monnier+emacs@HIDDEN> References: <87ed29ixu8.fsf@HIDDEN> Date: Sun, 15 Dec 2024 09:03:18 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.041 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74879 Cc: 74879 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Thank you for the recent addition of `trusted-content-p'. Is there a > possibility to use `trusted-content-p' in buffers which are not backed > by a file? I use Flymake in *scratch* or similar buffers and it seems > that this won't continue to work given that `trusted-content-p' needs a > `buffer-file-truename'. Good question. We don't really have a good answer yet, AFAIK, in large part because we don't have enough experience with it. Off the top of my head, here are some elements relevant to this discussion, in random order: - The current setup is a kind of "minimal" change for Emacs-30 because it's late in the pretest, so as much as possible we should separate the discussion into what's a simple enough solution for Emacs-30 and what we should use in the longer term. - You should be able to get fully-featured Flymake in *scratch* with (setq-local trusted-files :all). Maybe we should do that when we setup *scratch*? Which other non-file buffers would need that? The minibuffer? - Trust sucks, so we really should work on better solutions where we don't need to rely on trust, such as running code in `bwrap` or other kinds of sandboxes. - I think we do want some kind of hook, with which we can have (for instance) `emacs-lisp-mode` tell Emacs to trust the user init file, the early-init file, the custom-file, and all the files in `load-path`. - There is overlap with `safe-local-variable-directories`, `enable-local-variables` and it would be nice to consolidate (which can require delicate timing if we want the major mode to inform which content to trust). - Stefan
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 15 Dec 2024 13:55:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 15 08:55:45 2024 Received: from localhost ([127.0.0.1]:49970 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tMp60-0006zc-Se for submit <at> debbugs.gnu.org; Sun, 15 Dec 2024 08:55:45 -0500 Received: from mail-lj1-f171.google.com ([209.85.208.171]:59719) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1tMp5x-0006zJ-RN for 74879 <at> debbugs.gnu.org; Sun, 15 Dec 2024 08:55:43 -0500 Received: by mail-lj1-f171.google.com with SMTP id 38308e7fff4ca-303548a933aso1209671fa.3 for <74879 <at> debbugs.gnu.org>; Sun, 15 Dec 2024 05:55:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734270876; x=1734875676; 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=XUD2kDajcPQ7p+fmiLEhvuM0b+FtEaWkyF4ALcS/ZEQ=; b=VkCu6syFdYePYgApE/eWd16AC+Z1Q93XcOem5n4dkN3VwF/4Xj8QkOzn7yky5AjyG6 8mZItISUo6FBbxkah9p8tHsBf2Cr5x3Mf0Zczp64qV5/9gwonYJvL8B3v8L42crQNdEF tr/XJeOZBW8MiXZHx5JWSrBKKIqCk9InjEfjtEuSV+OnNX73IXEsfc0AoAS3bk6AHIZ+ rJWV/RGIjO/tHHdeaYKlxNt3joqyOTfKXH66DMUjgzo8ukKC4EhiDxwYSnBwPouxYWAw DjNJqRELg3rHvA+ry8aGaEYoXF+E5iS3gMzOjDk0RMtUNFxcylVDrbK+r0Q1CJMYj70y Uj/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734270876; x=1734875676; 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=XUD2kDajcPQ7p+fmiLEhvuM0b+FtEaWkyF4ALcS/ZEQ=; b=QJXLH8BJxRDJc4F/HTPcOW4cmMQm0R38/2MaCerqFc2rjgJEGHvML7LBTX3exa/VD1 woVnH8t0oBgUGQTzF3xOgCB9dL8lkpKxY2P3HirWOAI9lcoZMPxXJSOaW+87pF1As5p8 6wessXP1IL25eJ6chgylF9Meat+MvaoUV8552usU440j7rxjA1Lcit9p/WPHSe1CLji0 X68+8Z8yue1t/BnSdqBUltcIIxG5+rXVlGhGJS2tAXcZ4cUgdsqIn/t5RxoLZL7SA/bB tyZQK4MLWKvmEp0LCDHfscmAmTXTVnpKxWKeGzhjPRIbbOw2xOZFtonrSdHY99Xal/eX XmMg== X-Forwarded-Encrypted: i=1; AJvYcCXi3bnropAAmZRZiL/+43u/y/IlE00fwlpwb41RJF/q2b52A7yUhEtos95jFxxB8jP1eaNwoA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yw1NlYA2AZKBmiRj7S/cwo33taE5VhBbmxzw8GxuvTjDbBaM67h x6Ih+BlVK4ogWnzEhnwoxDfB6OFWG+WadPYSdmhp8yyF/wQDnANQEJT2fMuYebenDpV2uXDPjVG OpwGfY1JbE2Pe7zfmeBcvCl4gWbUT5/Do X-Gm-Gg: ASbGncvCmdB5e9a83wBoOif6P+viKuc3RE1HbzEqebL4qNm/4UkSyjtKfHRRPVpsaPj hdexVFLbuuHTXX2dZUN7wxwiWRNXbqubOSTGJgdk= X-Google-Smtp-Source: AGHT+IGu9gdeIl3Hgydo5ZBGp4IPeFzPAPLMLD/uhugj3kpgLPUJZBH2rQmZ/42Rg/tOy5+OX+h0RfGyWewfiUtwqts= X-Received: by 2002:a05:6402:5215:b0:5cf:a1c1:5289 with SMTP id 4fb4d7f45d1cf-5d63c3ecc35mr8659804a12.21.1734270362542; Sun, 15 Dec 2024 05:46:02 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sun, 15 Dec 2024 13:46:02 +0000 From: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <8634iprux9.fsf@HIDDEN> References: <87ed29ixu8.fsf@HIDDEN> <875xnlfdzi.fsf@HIDDEN> <86cyhtrzmo.fsf@HIDDEN> <87jzc1dxk2.fsf@HIDDEN> <868qshry7w.fsf@HIDDEN> <87y10hb2im.fsf@localhost> <8634iprux9.fsf@HIDDEN> MIME-Version: 1.0 Date: Sun, 15 Dec 2024 13:46:02 +0000 Message-ID: <CADwFkmkfVnbJyNFUEZ83Q+igo=T-GAiKa58_Q54mNZ7xBg9J+g@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers To: Eli Zaretskii <eliz@HIDDEN>, Ihor Radchenko <yantar92@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74879 Cc: mail@HIDDEN, 74879 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Ihor Radchenko <yantar92@HIDDEN> >> Cc: Daniel Mendler <mail@HIDDEN>, 74879 <at> debbugs.gnu.org, >> monnier@HIDDEN, stefankangas@HIDDEN >> Date: Sun, 15 Dec 2024 11:37:37 +0000 >> >> 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? If that's accepted, it doesn't need any function. > And can we really trust arbitrary ELisp code that to set trust? I can't speak for Ihor, but I didn't read what he said to mean that _all_ non-file-visiting buffer should be trusted. IIUC, the idea is to provide a mechanism that allows marking _some_ non-file-visiting buffers as trusted. This would be useful in *scratch* and ielm buffers, for example. > And what about buffers whose contents came from a network connection? > > What about buffers whose contents came from inserting some file or > part thereof, or were generated by processing some file? > > What about buffers whose contents came from a program Emacs invoked? Such buffers should still be untrusted.
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 15 Dec 2024 13:39:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 15 08:39:21 2024 Received: from localhost ([127.0.0.1]:49951 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tMoq8-0006BE-SJ for submit <at> debbugs.gnu.org; Sun, 15 Dec 2024 08:39:21 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56890) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tMoq1-0006Ar-NB for 74879 <at> debbugs.gnu.org; Sun, 15 Dec 2024 08:39:19 -0500 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 <eliz@HIDDEN>) 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==; Date: Sun, 15 Dec 2024 15:38:42 +0200 Message-Id: <86wmg1qd5p.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87cyht9kke.fsf@localhost> (message from Ihor Radchenko on Sun, 15 Dec 2024 12:50:41 +0000) Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers References: <87ed29ixu8.fsf@HIDDEN> <875xnlfdzi.fsf@HIDDEN> <86cyhtrzmo.fsf@HIDDEN> <87jzc1dxk2.fsf@HIDDEN> <868qshry7w.fsf@HIDDEN> <87y10hb2im.fsf@localhost> <8634iprux9.fsf@HIDDEN> <87cyht9kke.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74879 Cc: mail@HIDDEN, 74879 <at> debbugs.gnu.org, monnier@HIDDEN, stefankangas@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: mail@HIDDEN, 74879 <at> debbugs.gnu.org, monnier@HIDDEN, > stefankangas@HIDDEN > Date: Sun, 15 Dec 2024 12:50:41 +0000 > > Eli Zaretskii <eliz@HIDDEN> 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.
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 15 Dec 2024 12:49:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 15 07:49:31 2024 Received: from localhost ([127.0.0.1]:49848 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tMo3u-0003km-KS for submit <at> debbugs.gnu.org; Sun, 15 Dec 2024 07:49:31 -0500 Received: from mout01.posteo.de ([185.67.36.65]:54967) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1tMo3n-0003kK-1z for 74879 <at> debbugs.gnu.org; Sun, 15 Dec 2024 07:49:27 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 6D83E240027 for <74879 <at> 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== 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) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers In-Reply-To: <8634iprux9.fsf@HIDDEN> References: <87ed29ixu8.fsf@HIDDEN> <875xnlfdzi.fsf@HIDDEN> <86cyhtrzmo.fsf@HIDDEN> <87jzc1dxk2.fsf@HIDDEN> <868qshry7w.fsf@HIDDEN> <87y10hb2im.fsf@localhost> <8634iprux9.fsf@HIDDEN> Date: Sun, 15 Dec 2024 12:50:41 +0000 Message-ID: <87cyht9kke.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74879 Cc: mail@HIDDEN, 74879 <at> debbugs.gnu.org, monnier@HIDDEN, stefankangas@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> 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 <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 15 Dec 2024 12:32:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 15 07:32:15 2024 Received: from localhost ([127.0.0.1]:49833 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tMnnC-000311-Oo for submit <at> debbugs.gnu.org; Sun, 15 Dec 2024 07:32:15 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52772) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tMnn9-00030i-S9 for 74879 <at> debbugs.gnu.org; Sun, 15 Dec 2024 07:32:13 -0500 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 <eliz@HIDDEN>) id 1tMnko-000227-Gv; Sun, 15 Dec 2024 07:29:47 -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=K2YpTuZqzPuOBV7uTVAk4YJVKNREZDVPkIadFSgv/s4=; b=SlvVslTmcbWS LiK0B0+SZLIWnpHmNnt+SjmfF37KhoG0FerwDlDWnZvqxsJBzDNOX1ZIKLK9prnd7+Gbnn6+BFhrb JoGMD/SGpWDRBXotTWDu3f3nz6q9U9Kjp1Ku+VRqwcowXofBXrPsH4jTBNi7iMOFmGXJsOOPL7Ba5 c3cPNpt/e3Jx3y2X5MyBXLRM935AfV9nq0Ii5jHyLZT0J04t/3sZDT0GL74tiIUDO48QWAH9OaALJ 1NgbtN6lzuaDq8F07nIz/RoiN4p++0OFtdvovYs+uNXcIcmUrBEOHqSweQDh3VQEEKuewZ+JPxYnF jqy7I37j6fHcYItD2qGRwA==; Date: Sun, 15 Dec 2024 14:29:38 +0200 Message-Id: <8634iprux9.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87y10hb2im.fsf@localhost> (message from Ihor Radchenko on Sun, 15 Dec 2024 11:37:37 +0000) Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers References: <87ed29ixu8.fsf@HIDDEN> <875xnlfdzi.fsf@HIDDEN> <86cyhtrzmo.fsf@HIDDEN> <87jzc1dxk2.fsf@HIDDEN> <868qshry7w.fsf@HIDDEN> <87y10hb2im.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74879 Cc: mail@HIDDEN, 74879 <at> debbugs.gnu.org, monnier@HIDDEN, stefankangas@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: Daniel Mendler <mail@HIDDEN>, 74879 <at> debbugs.gnu.org, > monnier@HIDDEN, stefankangas@HIDDEN > Date: Sun, 15 Dec 2024 11:37:37 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > The question is serious: how do we envision this "trust" thing to work > > with buffers that don't visit files? If we are to change the code, > > certainly on the emacs-30 branch, we need a solid solution which > > provides more safety/security to users. Adding a variable doesn't > > solve a problem, it _adds_ a problem (how to populate the variable). > > Let me try. > > 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? If that's accepted, it doesn't need any function. And can we really trust arbitrary ELisp code that to set trust? And what about buffers whose contents came from a network connection? What about buffers whose contents came from inserting some file or part thereof, or were generated by processing some file? What about buffers whose contents came from a program Emacs invoked?
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 15 Dec 2024 11:36:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 15 06:36:21 2024 Received: from localhost ([127.0.0.1]:49739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tMmv5-0000Kl-MX for submit <at> debbugs.gnu.org; Sun, 15 Dec 2024 06:36:20 -0500 Received: from mout02.posteo.de ([185.67.36.66]:54015) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1tMmv3-0000KU-8f for 74879 <at> debbugs.gnu.org; Sun, 15 Dec 2024 06:36:18 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 8F13C240101 for <74879 <at> debbugs.gnu.org>; Sun, 15 Dec 2024 12:36:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1734262569; bh=ia9qpumZIYjzB+7i9H1IlUdWud1gRWXBoMgnsgtwy68=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=kO4PK5AxPA3CSHdeKvwtxZRKBueb7iPMh2wOyvzKlyACSerH/8l7G44eOL1WfgTrY Xt7JP2M3NkeOGgWpPQCsJ/qs69j08CPBzV0bNwGctQ7I41ghl5RPKDEZ0kLmpmLAmj aaOSFbyMt6txIxRfjTRwSYy8EK/jsBL3hCQHOAk6t21oan0BwQT4b0l1rzO/DH0/23 Ebow2GhHW4z+6r7f0uCbfRV0ADJLXSY6oYjik1HpSpmYod1oV6oUZw0KTPiFP2TrkN hwvHs4yAf5xhwMFafCP9ghRHzkb445eDvdyYMJCscdI0Go/wKdsEo4+hZ9SMr2AmdX UzQO/lSJb5fLw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YB1HD32jyz9rxG; Sun, 15 Dec 2024 12:36:08 +0100 (CET) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers In-Reply-To: <868qshry7w.fsf@HIDDEN> References: <87ed29ixu8.fsf@HIDDEN> <875xnlfdzi.fsf@HIDDEN> <86cyhtrzmo.fsf@HIDDEN> <87jzc1dxk2.fsf@HIDDEN> <868qshry7w.fsf@HIDDEN> Date: Sun, 15 Dec 2024 11:37:37 +0000 Message-ID: <87y10hb2im.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74879 Cc: Daniel Mendler <mail@HIDDEN>, 74879 <at> debbugs.gnu.org, monnier@HIDDEN, stefankangas@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> writes: > The question is serious: how do we envision this "trust" thing to work > with buffers that don't visit files? If we are to change the code, > certainly on the emacs-30 branch, we need a solid solution which > provides more safety/security to users. Adding a variable doesn't > solve a problem, it _adds_ a problem (how to populate the variable). Let me try. 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? -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 15 Dec 2024 11:18:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 15 06:18:47 2024 Received: from localhost ([127.0.0.1]:49706 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tMme2-0007tn-Ic for submit <at> debbugs.gnu.org; Sun, 15 Dec 2024 06:18:47 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35786) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tMmdy-0007tW-PR for 74879 <at> debbugs.gnu.org; Sun, 15 Dec 2024 06:18:40 -0500 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 <eliz@HIDDEN>) id 1tMmds-0000Lc-M0; Sun, 15 Dec 2024 06:18:32 -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=BLn+RGhzH3IIiAnCk5NA8GnuVzEWTSOJDjWFcGIkRl0=; b=dj7eQMj4mQQv qD0wGz/4c8NmbXU7WhIcQVZ46gKaNMWjDNzBcQuNQ7eP/1O4jX4jtAaDKuS/9Z/XC2DM+f6DGKON8 kx6zaPLUMTMv10tdIqzTn6LiPRQ0lyl0LIweeA2SdF4DvrYAcJH2vwp5rz5BauxxOvlgraX87Nyso IZO0aHIgnpHDP0bEkqrJK4KnqGXJh/E8d6mKqUT3LbkSlLhgGX8Iavh76t+YU8GNisy3Zpx20psBw yZ7McVomLGSfas3J0c2pSnkmcLrKfmX7fpSR5fgGbYkcv3qF8HKmieF7+u3i5Q1vqGAlHkKbv3VlU OvikEM3uHuQeTh00WFW6vw==; Date: Sun, 15 Dec 2024 13:18:27 +0200 Message-Id: <868qshry7w.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Daniel Mendler <mail@HIDDEN> In-Reply-To: <87jzc1dxk2.fsf@HIDDEN> (message from Daniel Mendler on Sun, 15 Dec 2024 11:56:29 +0100) Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers References: <87ed29ixu8.fsf@HIDDEN> <875xnlfdzi.fsf@HIDDEN> <86cyhtrzmo.fsf@HIDDEN> <87jzc1dxk2.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74879 Cc: 74879 <at> debbugs.gnu.org, monnier@HIDDEN, stefankangas@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Daniel Mendler <mail@HIDDEN> > Cc: 74879 <at> debbugs.gnu.org, monnier@HIDDEN, stefankangas@HIDDEN > Date: Sun, 15 Dec 2024 11:56:29 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > What do you envision trusted-buffer-function should do in a buffer > > that doesn't visit a file? > > `trusted-buffer-function' should be a hook variable, which could be set > to multiple functions, e.g., #'trusted--files-p and > #'trusted--buffers-p. The function `trusted--files-p' would check the > variable `trusted-files' similar to the existing code in the emacs-30 > branch. I was asking specifically about the non file-visiting buffers. > The function `trusted--buffers-p' could check another variable > `trusted-buffers' which specifies a list of buffer name regexps or > probably even better a `buffer-match-p' condition. This way the user > could specify buffers which they consider safe, for example *scratch*. Why would a buffer's name tell _anything_ about whether the user can trust it? > In the end it is up to the user how the variables are configured, as is > already the case with `trusted-files'. The user must define which > directories/files/buffers they consider safe. If we wanted to let this completely up to the user, we wouldn't be introducing this feature, certainly not so close to a release, would we? The question is serious: how do we envision this "trust" thing to work with buffers that don't visit files? If we are to change the code, certainly on the emacs-30 branch, we need a solid solution which provides more safety/security to users. Adding a variable doesn't solve a problem, it _adds_ a problem (how to populate the variable).
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 15 Dec 2024 10:56:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 15 05:56:42 2024 Received: from localhost ([127.0.0.1]:49672 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tMmIk-0006u3-C5 for submit <at> debbugs.gnu.org; Sun, 15 Dec 2024 05:56:42 -0500 Received: from server.qxqx.de ([49.12.34.165]:54899 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1tMmIf-0006tk-Gq for 74879 <at> debbugs.gnu.org; Sun, 15 Dec 2024 05:56:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uTPZCG1T5NRegiRmSwMhDd40/uaZ6mJIvJwaDpNeUxY=; b=IxgAbZKrKrrgBOUZNKHd+uLaaS Nw2g2q58KxnDZ0OrzIZUNyco2DRz8NnD36VqC+ehcoNPV0nMM+8FJBbBGqLrhrMVQpMhh0MAct61f QyRU+4FFkzcKDab+orFRfjRnz04JOJUUc1cTt4uogkDBPvMJYWllYGD9nUH6/N8A6Xwg=; From: Daniel Mendler <mail@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers In-Reply-To: <86cyhtrzmo.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 15 Dec 2024 12:47:59 +0200") References: <87ed29ixu8.fsf@HIDDEN> <875xnlfdzi.fsf@HIDDEN> <86cyhtrzmo.fsf@HIDDEN> Date: Sun, 15 Dec 2024 11:56:29 +0100 Message-ID: <87jzc1dxk2.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74879 Cc: 74879 <at> debbugs.gnu.org, monnier@HIDDEN, stefankangas@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> Cc: Stefan Monnier <monnier@HIDDEN>, >> Stefan Kangas <stefankangas@HIDDEN> >> Date: Sun, 15 Dec 2024 11:16:17 +0100 >> From: Daniel Mendler via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> >> >> Daniel Mendler <mail@HIDDEN> writes: >> >> > Thank you for the recent addition of `trusted-content-p'. Is there a >> > possibility to use `trusted-content-p' in buffers which are not backed >> > by a file? I use Flymake in *scratch* or similar buffers and it seems >> > that this won't continue to work given that `trusted-content-p' needs a >> > `buffer-file-truename'. >> > >> > My suggestion would be to replace `trusted-files' by a >> > `trusted-buffer-function' which is a predicate function or a list of >> > functions. The functions could then check a custom list of trusted files >> > or a custom list of trusted buffers. >> > >> > Alternatively offer `trusted-files', `trusted-buffers' and >> > `trusted-buffer-function`? `trusted-buffers' could for example rely on >> > `buffer-match-p`. >> >> I have also ported back `trusted-content-p' via Compat. I had the plan >> to use `trusted-content-p' in external packages which could potentially >> perform dangerous operations. This way the new feature can be used to >> retroactively improve the safety even of older Emacs installations. >> >> For example in my GNU ELPA Corfu package the plan was to check >> `(trusted-content-p)' when starting auto completion. 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. >> >> Now with the limitation of `trusted-content-p' to file-backed buffers, I >> cannot do this, since otherwise auto completion would be lost for >> example in *scratch* buffers. Each package could invent its own trust >> mechanism or alternatively one could limit the `trusted-content-p' check >> to only file-backed buffers. Both alternatives would be worse than going >> through the `trusted-content-p' standard mechanism. >> >> Therefore by making the `trusted-content-p' mechanism too limited, we >> get less safety than with a more flexible mechanism. Nevertheless I >> would avoid creating a complex mechanism given that the mechanism is >> supposed to be part of Emacs 30. The simplest approach I can think of >> this this `trusted-buffer-function', a hook called by >> `run-hook-with-args-until-success'. Later on trust functions can be >> provided and added to the hook list. The trust functions could check >> file lists, buffer lists, regexps etc. Users can also write their own >> predicate functions. > > What do you envision trusted-buffer-function should do in a buffer > that doesn't visit a file? `trusted-buffer-function' should be a hook variable, which could be set to multiple functions, e.g., #'trusted--files-p and #'trusted--buffers-p. The function `trusted--files-p' would check the variable `trusted-files' similar to the existing code in the emacs-30 branch. The function `trusted--buffers-p' could check another variable `trusted-buffers' which specifies a list of buffer name regexps or probably even better a `buffer-match-p' condition. This way the user could specify buffers which they consider safe, for example *scratch*. In the end it is up to the user how the variables are configured, as is already the case with `trusted-files'. The user must define which directories/files/buffers they consider safe. Daniel
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at 74879) by debbugs.gnu.org; 15 Dec 2024 10:48:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 15 05:48:31 2024 Received: from localhost ([127.0.0.1]:49661 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tMmAp-0006UW-4g for submit <at> debbugs.gnu.org; Sun, 15 Dec 2024 05:48:31 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57182) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tMmAk-0006UA-8h for 74879 <at> debbugs.gnu.org; Sun, 15 Dec 2024 05:48:28 -0500 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 <eliz@HIDDEN>) id 1tMmAd-0004Ou-Hu; Sun, 15 Dec 2024 05:48:19 -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=MMWY+VTMMCSa/qsIXnMHAoE4lSbKBgUZKTOzgWwhYwM=; b=YpPamtppnSsT JT+0kALLcgcag0EAiN+j/Spwv+kUsX+PoNMhFun5LEYXvQY2jBgVe7ULNPMw3KT8zLqIxYus/0wi1 7GKp1DZocI/D18024BhIHvMCkYz6s9IUroDAsqDqlJFcfhRP6QxaQoIuh2V1uM54veTmvhuJAQlhO RESGt8+k8umgJ+a9I1JtBe3ZyxN4PUDtxqElw0oMld7WR+QTBIjPyMW+cVa//L55Yj3jPXyVigAJc J9fm0/ldXQ/Ie1C7u590ncPxIxDDHPqZC55xFHM0CXLQEs/1QsyUAhP1zoMiSRKkjVTdwXyxgUuBP F+bTrekhfPv1HknmikM9/Q==; Date: Sun, 15 Dec 2024 12:47:59 +0200 Message-Id: <86cyhtrzmo.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Daniel Mendler <mail@HIDDEN> In-Reply-To: <875xnlfdzi.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers References: <87ed29ixu8.fsf@HIDDEN> <875xnlfdzi.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74879 Cc: 74879 <at> debbugs.gnu.org, monnier@HIDDEN, stefankangas@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: Stefan Monnier <monnier@HIDDEN>, > Stefan Kangas <stefankangas@HIDDEN> > Date: Sun, 15 Dec 2024 11:16:17 +0100 > From: Daniel Mendler via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > Daniel Mendler <mail@HIDDEN> writes: > > > Thank you for the recent addition of `trusted-content-p'. Is there a > > possibility to use `trusted-content-p' in buffers which are not backed > > by a file? I use Flymake in *scratch* or similar buffers and it seems > > that this won't continue to work given that `trusted-content-p' needs a > > `buffer-file-truename'. > > > > My suggestion would be to replace `trusted-files' by a > > `trusted-buffer-function' which is a predicate function or a list of > > functions. The functions could then check a custom list of trusted files > > or a custom list of trusted buffers. > > > > Alternatively offer `trusted-files', `trusted-buffers' and > > `trusted-buffer-function`? `trusted-buffers' could for example rely on > > `buffer-match-p`. > > I have also ported back `trusted-content-p' via Compat. I had the plan > to use `trusted-content-p' in external packages which could potentially > perform dangerous operations. This way the new feature can be used to > retroactively improve the safety even of older Emacs installations. > > For example in my GNU ELPA Corfu package the plan was to check > `(trusted-content-p)' when starting auto completion. 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. > > Now with the limitation of `trusted-content-p' to file-backed buffers, I > cannot do this, since otherwise auto completion would be lost for > example in *scratch* buffers. Each package could invent its own trust > mechanism or alternatively one could limit the `trusted-content-p' check > to only file-backed buffers. Both alternatives would be worse than going > through the `trusted-content-p' standard mechanism. > > Therefore by making the `trusted-content-p' mechanism too limited, we > get less safety than with a more flexible mechanism. Nevertheless I > would avoid creating a complex mechanism given that the mechanism is > supposed to be part of Emacs 30. The simplest approach I can think of > this this `trusted-buffer-function', a hook called by > `run-hook-with-args-until-success'. Later on trust functions can be > provided and added to the hook list. The trust functions could check > file lists, buffer lists, regexps etc. Users can also write their own > predicate functions. What do you envision trusted-buffer-function should do in a buffer that doesn't visit a file?
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 15 Dec 2024 10:16:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 15 05:16:32 2024 Received: from localhost ([127.0.0.1]:49625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tMlfr-00051q-Qi for submit <at> debbugs.gnu.org; Sun, 15 Dec 2024 05:16:32 -0500 Received: from lists.gnu.org ([209.51.188.17]:54810) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1tMlfm-00051e-VM for submit <at> debbugs.gnu.org; Sun, 15 Dec 2024 05:16:28 -0500 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 <mail@HIDDEN>) id 1tMlfl-0003ZN-SJ for bug-gnu-emacs@HIDDEN; Sun, 15 Dec 2024 05:16:26 -0500 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1] helo=mail.qxqx.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <mail@HIDDEN>) id 1tMlfj-0008IX-Em for bug-gnu-emacs@HIDDEN; Sun, 15 Dec 2024 05:16:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=33QeVtvxeY+6euQQW5OksZYOiTaTQI8hiax5edahtWU=; b=KIkXVBzeo48zXZS4qj98rHkPOV 35sChT9BnhQtCWcT6xAtbA4Gv+FtdlSgLchcQDk47dJhdKlXePe15cb2dSrwehGL4CDsDxa5EPJwk NMOm1+KBXqIvaFbfr5MBnRCtLvESr9yyd7NSSELeb1J+WWII4A1CVKNFN2/YYNsSsvjo=; From: Daniel Mendler <mail@HIDDEN> To: bug-gnu-emacs@HIDDEN Subject: Re: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers In-Reply-To: <87ed29ixu8.fsf@HIDDEN> (Daniel Mendler's message of "Sun, 15 Dec 2024 01:39:11 +0100") References: <87ed29ixu8.fsf@HIDDEN> Date: Sun, 15 Dec 2024 11:16:17 +0100 Message-ID: <875xnlfdzi.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a01:4f8:c012:9177::1; envelope-from=mail@HIDDEN; helo=mail.qxqx.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: Stefan Monnier <monnier@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.4 (--) Daniel Mendler <mail@HIDDEN> writes: > Thank you for the recent addition of `trusted-content-p'. Is there a > possibility to use `trusted-content-p' in buffers which are not backed > by a file? I use Flymake in *scratch* or similar buffers and it seems > that this won't continue to work given that `trusted-content-p' needs a > `buffer-file-truename'. > > My suggestion would be to replace `trusted-files' by a > `trusted-buffer-function' which is a predicate function or a list of > functions. The functions could then check a custom list of trusted files > or a custom list of trusted buffers. > > Alternatively offer `trusted-files', `trusted-buffers' and > `trusted-buffer-function`? `trusted-buffers' could for example rely on > `buffer-match-p`. I have also ported back `trusted-content-p' via Compat. I had the plan to use `trusted-content-p' in external packages which could potentially perform dangerous operations. This way the new feature can be used to retroactively improve the safety even of older Emacs installations. For example in my GNU ELPA Corfu package the plan was to check `(trusted-content-p)' when starting auto completion. 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. Now with the limitation of `trusted-content-p' to file-backed buffers, I cannot do this, since otherwise auto completion would be lost for example in *scratch* buffers. Each package could invent its own trust mechanism or alternatively one could limit the `trusted-content-p' check to only file-backed buffers. Both alternatives would be worse than going through the `trusted-content-p' standard mechanism. Therefore by making the `trusted-content-p' mechanism too limited, we get less safety than with a more flexible mechanism. Nevertheless I would avoid creating a complex mechanism given that the mechanism is supposed to be part of Emacs 30. The simplest approach I can think of this this `trusted-buffer-function', a hook called by `run-hook-with-args-until-success'. Later on trust functions can be provided and added to the hook list. The trust functions could check file lists, buffer lists, regexps etc. Users can also write their own predicate functions. In any case, I am happy to help providing patches. Daniel
bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 15 Dec 2024 00:39:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 14 19:39:22 2024 Received: from localhost ([127.0.0.1]:48882 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tMcfJ-0001m5-QT for submit <at> debbugs.gnu.org; Sat, 14 Dec 2024 19:39:22 -0500 Received: from lists.gnu.org ([209.51.188.17]:43374) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1tMcfI-0001lv-80 for submit <at> debbugs.gnu.org; Sat, 14 Dec 2024 19:39:20 -0500 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 <mail@HIDDEN>) id 1tMcfH-00049z-OW for bug-gnu-emacs@HIDDEN; Sat, 14 Dec 2024 19:39:20 -0500 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1] helo=mail.qxqx.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <mail@HIDDEN>) id 1tMcfD-0006ew-NS for bug-gnu-emacs@HIDDEN; Sat, 14 Dec 2024 19:39:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=TbhnHbeko1VglSUhATbNuy3IFt4VmiTqssWERN/Qheo=; b=QFAALO/5I6z6ucL6gSjtlSnI/4 BcfBzym21RBKWPW7ORW30llnpGr0VKgHGo7XXnXC7Y9HIF1GRyMnK/G4knafYK9pYelXetqYxMWiF n3nH67xNaB1DoTFOLfZhA9+vtcaZYFFYb+s0h5iMaKD2NA1AZOdFk9jpMyR5xyUDMdV8=; From: Daniel Mendler <mail@HIDDEN> To: bug-gnu-emacs@HIDDEN Subject: 30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers X-Debbugs-Cc: Stefan Monnier <monnier@HIDDEN> Date: Sun, 15 Dec 2024 01:39:11 +0100 Message-ID: <87ed29ixu8.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a01:4f8:c012:9177::1; envelope-from=mail@HIDDEN; helo=mail.qxqx.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.4 (--) Thank you for the recent addition of `trusted-content-p'. Is there a possibility to use `trusted-content-p' in buffers which are not backed by a file? I use Flymake in *scratch* or similar buffers and it seems that this won't continue to work given that `trusted-content-p' needs a `buffer-file-truename'. My suggestion would be to replace `trusted-files' by a `trusted-buffer-function' which is a predicate function or a list of functions. The functions could then check a custom list of trusted files or a custom list of trusted buffers. Alternatively offer `trusted-files', `trusted-buffers' and `trusted-buffer-function`? `trusted-buffers' could for example rely on `buffer-match-p`. Daniel
Daniel Mendler <mail@HIDDEN>:monnier@HIDDEN, bug-gnu-emacs@HIDDEN.
Full text available.monnier@HIDDEN, bug-gnu-emacs@HIDDEN:bug#74879; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.