Re: Request to backport fix for CVE-2022-45939 to Emacs 28

[Tim Cross]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: lux <lx@shellcodes.org>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 14 Feb 2023 13:07:44 +0800
>> 
>> Hi, I can fix the CVE-2022-45939, this is a patch.
>
> We don't need a patch for that, we just need to cherry-pick the
> related commits from emacs-29.
>
> But that is not what the OP requested: he requested that we also
> produce an Emacs 28.3 release.  And that is a much larger job, for
> which we currently don't have the time or resources.

While I understand the resourcing issues, I think this is the wrong
decision. We are in the situation where the current released version of
Emacs has a known security exploit with a severity classification of
high (although this assessment seems to be under review) and the
response seems to be "Sorry, we are too busy trying to get the next
version released to deal with this". If we were actually close to an
Emacs 29 release, then perhaps this would be reasonable, but we don't
even have a release candidate out yet.

Failing to address a high security vulnerability for months is a
disservice for the emacs user base and likely to be a blight on Emacs'
reputation and only provides those against free software with free
ammunition. In addition to the technical aspects of a security
vulnerability, perception is just as important. While the specific
technical aspects of this vulnerability would seem to indicate only a
subset of etags users are actually exposed to this risk, such detail is
likely to be lost amongst the FUD which tends to accompany security
issues.