GNU bug report logs - #74879
30.0.92; trusted-content-p and trusted-files cannot be used for non-file buffers

Previous Next

Full log

Message #98 received at 74879 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 74879 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#74879: 30.0.92; trusted-content-p and trusted-files cannot be
 used for non-file buffers
Date: Tue, 17 Dec 2024 03:42:16 +0200

On 16/12/2024 15:41, Daniel Mendler wrote:
> Dmitry Gutov <dmitry <at> gutov.dev> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.