emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacs-29 3c1693d08b0: Fix Elisp code injection vulnerability in emac


From: Po Lu
Subject: Re: emacs-29 3c1693d08b0: Fix Elisp code injection vulnerability in emacsclient-mail.desktop
Date: Thu, 09 Mar 2023 18:22:09 +0800
User-agent: Gnus/5.13 (Gnus v5.13)

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Wed, 8 Mar 2023 10:54:08 -0800, Jim Porter <jporterbugs@gmail.com> 
>>>>>> said:
>
>     Jim> 'set-arg' is probably simple enough that we could expect users to
>     Jim> write it themselves. '--apply' is a bit tricky (for emacsclient at
>     Jim> least), since we'd need to properly escape strings. I guess the
>     Jim> complexity of doing this would depend on how we did the escaping
>     Jim> though.
>
> Iʼm not sure what escaping is needed. We take each command line
> argument and pass it to emacs wrapped in "" so itʼs treated as a
> string.
>
>     Jim> For reference for this thread, the conclusion we came to in bug#57752
>     Jim> was an interface like this:
>
>     Jim>   emacs --apply func1 arg1 arg2 -- --apply func2 arg3 arg4
>
>     Jim> (Ditto for emacsclient.)
>
> Thatʼs not that easy to do with our current usage of getopt. For
> emacsclient, OTOH, the following is pretty easy to support without any
> changes to server.el
>
>     emacsclient --apply func arg1 arg2
>
> since --apply can (ab)use --eval internally.
>
> Robert

I'm not quite familiar with emacsclient, but can't we have emacsclient
run Lisp from stdin?  That sounds much more flexible.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]