Re: Fixing security vulnerabilities before new releases

Manuel Giraud <[email protected]> Wed, 29 Jul 2026 19:25:24 +0200
Newsgroups gmane.emacs.devel
Message-ID <[email protected]>
Eshel Yaron <[email protected]> writes:

> Sean Whitton <[email protected]> writes:
>
>> Eshel Yaron [29/Jul  1:16pm +02] wrote:
>>> Sean Whitton <[email protected]> writes:
>>>> Eshel Yaron [28/Jul  6:52pm +02] wrote:
>>>>>
>>>>> Please consider waiting for some mitigation for the vulnerability Stefan
>>>>> described in bug#80574.
>>>>> It's a serious security concern, better fix it before the release.
>>>>
>>>> That bug is present in Emacs 30, so 31.1 release does not need to wait
>>>> on it.  As soon as we have a fix we are happy with we will do another
>>>> point release.
>>>
>>> Hmm...  There's an arbitrary code execution vulnerability that makes
>>> opening files with Emacs unsafe.  Indeed, it affects existing Emacs
>>> versions as well---that's a good reason to mitigate it ASAP and maybe
>>> provide a security fix for Emacs 30, but it wouldn't make sense to
>>> release another vulnerable version.
>>> ISTM that if anything is a release-blocker, this is it.
>>
>> I don't understand your reasoning at all here.  We do not make the
>> situation worse by releasing Emacs 31.  Therefore the issues are not
>> interdependent.
>
> OK, let me try to clarify it further:
> Releasing a new version invites more users to install and use it,
> and encouraging users to run vulnerable software is at best a disservice.
> True, it wouldn't make things worse for users who are already running a
> vulnerable version, but I don't think that's the right bar to aim for.
> Instead, we should make sure we make things better for them, by providing
> a version that mitigates this issue ASAP.  AFAICT, releasing a vulnerable
> Emacs 31.1 would delay that mitigation unnecessarily.
>
> To be clear, I think a mitigation can be rather simple/straightforward,
> and it doesn't have to be the permanent solution.  I'd recommend
> releasing Emacs 31 with a "bandaid" solution (I can suggest something if
> you agree), and fixing it properly in a later release.

Hi Eshel,

I'm with you and Óscar on this one but FWIW I was not able to reproduce
the code execution example given by Stefan.  Writing the following in
/tmp/test.el and opening it doesn't do anything for me (I'm on current
master):

--8<---------------cut here---------------start------------->8---
;; -*- lexical-binding: t; -*-
    
(yes-or-no-p "Gotcha? ")

;; Local Variables:
;; read-symbol-shorthands: (("vc-cvs-registered" . "load"))
;; End:
--8<---------------cut here---------------end--------------->8---

What am I missing?
-- 
Manuel Giraud