From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: release bugs [was Re: Processed: enriched.el code execution] Date: Thu, 07 Sep 2017 18:03:28 +0300 Message-ID: <83wp5azh33.fsf@gnu.org> References: <83tw0h0yem.fsf@gnu.org> <83lglr24ck.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1504796778 19168 195.159.176.226 (7 Sep 2017 15:06:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 7 Sep 2017 15:06:18 +0000 (UTC) Cc: rgm@gnu.org, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 07 17:06:02 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dpyMz-00039i-HX for ged-emacs-devel@m.gmane.org; Thu, 07 Sep 2017 17:05:29 +0200 Original-Received: from localhost ([::1]:40841 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dpyN6-0002UI-Kb for ged-emacs-devel@m.gmane.org; Thu, 07 Sep 2017 11:05:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41787) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dpyLA-0001pA-O6 for emacs-devel@gnu.org; Thu, 07 Sep 2017 11:03:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dpyL1-00069s-9a for emacs-devel@gnu.org; Thu, 07 Sep 2017 11:03:36 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59501) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dpyL1-00069o-5k; Thu, 07 Sep 2017 11:03:27 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1906 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dpyL0-0003MJ-70; Thu, 07 Sep 2017 11:03:26 -0400 In-reply-to: (message from Paul Eggert on Wed, 6 Sep 2017 23:30:15 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:217980 Archived-At: > Cc: emacs-devel@gnu.org > From: Paul Eggert > Date: Wed, 6 Sep 2017 23:30:15 -0700 > > Eli Zaretskii wrote: > > Or maybe we could discuss the criteria for blocking bugs, and if > > agreed, no further discussions would be necessary. > > This particular bug involved remote code execution by visiting an email > attachment. Any security hole this serious should be blocking. It doesn't matter > that the bug has been around for a while, as the bug is known now and is likely > to be exploited by anyone who cares to attack Emacs users. I'm surprised that > there was controversy about this case, as the bug really should be fixed as soon > as we reasonably can, or in any event before the next release. There's no controversy regarding the need to fix serious security bugs, such as this one. However, marking a bug as blocking doesn't fix it, only code changes will fix it. If this bug is indeed deemed urgent by the community, it will be fixed very soon, and in that case blocking the next release, which will not happen tomorrow or the next week, is meaningless. OTOH, if the bug will remain unfixed till we are ready to release Emacs 26.1, in, like, 6 months, then it means fixing it is not deemed important, and blocking the release for it makes no sense.