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