Fixing security vulnerabilities before new releases (was: Emacs 31 release-blocking bugs)

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.


Thanks,

Eshel

P.S. my 'trust-manager' package provides a rough mitigation for this
vulnerability that protects users in existing Emacs versions.  I'd really
like to disable this mitigation when the package is used in Emacs 31. :)