all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* release bugs [was Re: Processed: enriched.el code execution]
       [not found] ` <handler.s.C.150463767313430.transcript@debbugs.gnu.org>
@ 2017-09-06  6:40   ` Glenn Morris
  2017-09-06  9:41     ` John Wiegley
  2017-09-06 16:12     ` Eli Zaretskii
  0 siblings, 2 replies; 19+ messages in thread
From: Glenn Morris @ 2017-09-06  6:40 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel


Re https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28350;msg=13

Eli Zaretskii wrote:

> unblock 24655 by 28350

I'm surprised that you don't want to motivate people to fix security
vulnerabilities for the next release.

Anyway, I'll stop adding to list of release bugs, since it feels unproductive.
(FTR, no-one else has added anything in the past six months.)



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: release bugs [was Re: Processed: enriched.el code execution]
  2017-09-06  6:40   ` release bugs [was Re: Processed: enriched.el code execution] Glenn Morris
@ 2017-09-06  9:41     ` John Wiegley
  2017-09-06 10:00       ` Sven Joachim
  2017-09-06 16:12     ` Eli Zaretskii
  1 sibling, 1 reply; 19+ messages in thread
From: John Wiegley @ 2017-09-06  9:41 UTC (permalink / raw)
  To: Glenn Morris; +Cc: Eli Zaretskii, emacs-devel

>>>>> "GM" == Glenn Morris <rgm@gnu.org> writes:

GM> I'm surprised that you don't want to motivate people to fix security
GM> vulnerabilities for the next release.

Which security issues do you consider particularly awful?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: release bugs [was Re: Processed: enriched.el code execution]
  2017-09-06  9:41     ` John Wiegley
@ 2017-09-06 10:00       ` Sven Joachim
  2017-09-06 10:13         ` John Wiegley
  2017-09-07  4:03         ` Richard Stallman
  0 siblings, 2 replies; 19+ messages in thread
From: Sven Joachim @ 2017-09-06 10:00 UTC (permalink / raw)
  To: emacs-devel; +Cc: Glenn Morris, Eli Zaretskii

On 2017-09-06 10:41 +0100, John Wiegley wrote:

>>>>>> "GM" == Glenn Morris <rgm@gnu.org> writes:
>
> GM> I'm surprised that you don't want to motivate people to fix security
> GM> vulnerabilities for the next release.
>
> Which security issues do you consider particularly awful?

Well, #28350 looks pretty awful considering that the code execution
happens when you visit a mail attachment, for instance.  Has anyone
requested a CVE for this yet, BTW?

Cheers,
       Sven



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: release bugs [was Re: Processed: enriched.el code execution]
  2017-09-06 10:00       ` Sven Joachim
@ 2017-09-06 10:13         ` John Wiegley
  2017-09-07  4:03         ` Richard Stallman
  1 sibling, 0 replies; 19+ messages in thread
From: John Wiegley @ 2017-09-06 10:13 UTC (permalink / raw)
  To: Sven Joachim; +Cc: Glenn Morris, Eli Zaretskii, emacs-devel

>>>>> "SJ" == Sven Joachim <svenjoac@gmx.de> writes:

SJ> Well, #28350 looks pretty awful considering that the code execution
SJ> happens when you visit a mail attachment, for instance. Has anyone
SJ> requested a CVE for this yet, BTW?

I'm not aware of a CVE, but the reporter has said he'll be committing a fix
shortly.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: release bugs [was Re: Processed: enriched.el code execution]
  2017-09-06  6:40   ` release bugs [was Re: Processed: enriched.el code execution] Glenn Morris
  2017-09-06  9:41     ` John Wiegley
@ 2017-09-06 16:12     ` Eli Zaretskii
  2017-09-07  6:30       ` Paul Eggert
  1 sibling, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2017-09-06 16:12 UTC (permalink / raw)
  To: Glenn Morris; +Cc: emacs-devel

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 06 Sep 2017 02:40:05 -0400
> 
> 
> I'm surprised that you don't want to motivate people to fix security
> vulnerabilities for the next release.

I do, I just don't see how can I justify delaying a release due to an
issue that was with us since 1999.

> Anyway, I'll stop adding to list of release bugs, since it feels unproductive.

It isn't unproductive, and I appreciate it very much that you are
doing it.  I just wish you'd do it publicly, at least in controversial
cases such as this one.

Or maybe we could discuss the criteria for blocking bugs, and if
agreed, no further discussions would be necessary.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: release bugs [was Re: Processed: enriched.el code execution]
  2017-09-06 10:00       ` Sven Joachim
  2017-09-06 10:13         ` John Wiegley
@ 2017-09-07  4:03         ` Richard Stallman
  2017-09-07 14:43           ` Eli Zaretskii
  1 sibling, 1 reply; 19+ messages in thread
From: Richard Stallman @ 2017-09-07  4:03 UTC (permalink / raw)
  To: Sven Joachim; +Cc: rgm, eliz, emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Well, #28350 looks pretty awful considering that the code execution
  > happens when you visit a mail attachment, for instance.

Indeed, that kind of bug is a terrible one.
We must not make a release with such a bug.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: release bugs [was Re: Processed: enriched.el code execution]
  2017-09-06 16:12     ` Eli Zaretskii
@ 2017-09-07  6:30       ` Paul Eggert
  2017-09-07 13:11         ` John Wiegley
                           ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Paul Eggert @ 2017-09-07  6:30 UTC (permalink / raw)
  To: Eli Zaretskii, Glenn Morris; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: release bugs [was Re: Processed: enriched.el code execution]
  2017-09-07  6:30       ` Paul Eggert
@ 2017-09-07 13:11         ` John Wiegley
  2017-09-07 15:03         ` Eli Zaretskii
  2017-09-07 20:47         ` enriched.el code execution Reiner Steib
  2 siblings, 0 replies; 19+ messages in thread
From: John Wiegley @ 2017-09-07 13:11 UTC (permalink / raw)
  To: Paul Eggert; +Cc: Glenn Morris, Eli Zaretskii, emacs-devel

>>>>> "PE" == Paul Eggert <eggert@cs.ucla.edu> writes:

PE> This particular bug involved remote code execution by visiting an email
PE> attachment. Any security hole this serious should be blocking. It doesn't
PE> matter that the bug has been around for a while, as the bug is known now
PE> and is likely to be exploited by anyone who cares to attack Emacs users.
PE> I'm surprised that there was controversy about this case, as the bug
PE> really should be fixed as soon as we reasonably can, or in any event
PE> before the next release.

It does seem that this issue should be easy enough to fix that we can delay
until it's included.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: release bugs [was Re: Processed: enriched.el code execution]
  2017-09-07  4:03         ` Richard Stallman
@ 2017-09-07 14:43           ` Eli Zaretskii
  0 siblings, 0 replies; 19+ messages in thread
From: Eli Zaretskii @ 2017-09-07 14:43 UTC (permalink / raw)
  To: rms; +Cc: rgm, svenjoac, emacs-devel

> From: Richard Stallman <rms@gnu.org>
> CC: emacs-devel@gnu.org, rgm@gnu.org, eliz@gnu.org
> Date: Thu, 07 Sep 2017 00:03:09 -0400
> 
>   > Well, #28350 looks pretty awful considering that the code execution
>   > happens when you visit a mail attachment, for instance.
> 
> Indeed, that kind of bug is a terrible one.
> We must not make a release with such a bug.

The person who discovered this is working on a fix, so we should be
fine.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: release bugs [was Re: Processed: enriched.el code execution]
  2017-09-07  6:30       ` Paul Eggert
  2017-09-07 13:11         ` John Wiegley
@ 2017-09-07 15:03         ` Eli Zaretskii
  2017-09-07 21:32           ` Paul Eggert
  2017-09-07 20:47         ` enriched.el code execution Reiner Steib
  2 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2017-09-07 15:03 UTC (permalink / raw)
  To: Paul Eggert; +Cc: rgm, emacs-devel

> Cc: emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 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.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: enriched.el code execution
  2017-09-07  6:30       ` Paul Eggert
  2017-09-07 13:11         ` John Wiegley
  2017-09-07 15:03         ` Eli Zaretskii
@ 2017-09-07 20:47         ` Reiner Steib
  2017-09-07 21:24           ` Paul Eggert
  2 siblings, 1 reply; 19+ messages in thread
From: Reiner Steib @ 2017-09-07 20:47 UTC (permalink / raw)
  To: Paul Eggert; +Cc: Eli Zaretskii, emacs-devel

On Wed, Sep 06 2017, Paul Eggert wrote:

> 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.

If I understand correctly, this issue is serious enough (CVSS is 8.8,
Common Vulnerability Scoring System, v3.0) that we should prepare a
security fix release (from Emacs 25.2) as soon as we have a fix for
this bug (or we should disable this feature of enriched mode).

Bye, Reiner.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: enriched.el code execution
  2017-09-07 20:47         ` enriched.el code execution Reiner Steib
@ 2017-09-07 21:24           ` Paul Eggert
  0 siblings, 0 replies; 19+ messages in thread
From: Paul Eggert @ 2017-09-07 21:24 UTC (permalink / raw)
  To: Eli Zaretskii, emacs-devel

Reiner Steib wrote:
> If I understand correctly, this issue is serious enough (CVSS is 8.8,
> Common Vulnerability Scoring System, v3.0) that we should prepare a
> security fix release (from Emacs 25.2) as soon as we have a fix for
> this bug (or we should disable this feature of enriched mode).

I favor this as well. Although I hate maintaining the old branch, this bug is 
quite serious.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: release bugs [was Re: Processed: enriched.el code execution]
  2017-09-07 15:03         ` Eli Zaretskii
@ 2017-09-07 21:32           ` Paul Eggert
  2017-09-08  6:55             ` Eli Zaretskii
  0 siblings, 1 reply; 19+ messages in thread
From: Paul Eggert @ 2017-09-07 21:32 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rgm, emacs-devel

Eli Zaretskii wrote:
> 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.

A similar argument could be applied to any blocking bug, so why bother to mark 
any bug as blocking?

I find value in having even easily-fixed bugs marked as blocking, if the bugs 
are important (as this one surely is).



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: release bugs [was Re: Processed: enriched.el code execution]
  2017-09-07 21:32           ` Paul Eggert
@ 2017-09-08  6:55             ` Eli Zaretskii
  2017-09-08  7:11               ` Paul Eggert
  0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2017-09-08  6:55 UTC (permalink / raw)
  To: Paul Eggert; +Cc: rgm, emacs-devel

> Cc: rgm@gnu.org, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 7 Sep 2017 14:32:48 -0700
> 
> Eli Zaretskii wrote:
> > 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.
> 
> A similar argument could be applied to any blocking bug

No, it cannot.  The point is that marking bugs as blocking and their
urgency are two different and almost independent issues.

> so why bother to mark any bug as blocking?

Because it helps in management of a release.  It's a managerial tool.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: release bugs [was Re: Processed: enriched.el code execution]
  2017-09-08  6:55             ` Eli Zaretskii
@ 2017-09-08  7:11               ` Paul Eggert
  2017-09-08  8:20                 ` Fabrice Popineau
  0 siblings, 1 reply; 19+ messages in thread
From: Paul Eggert @ 2017-09-08  7:11 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rgm, emacs-devel

Eli Zaretskii wrote:
> marking bugs as blocking and their
> urgency are two different and almost independent issues.

They are different but not that independent. Urgent bugs are considerably more 
likely to be blocking (i.e., they should be fixed before the next release) than 
non-urgent bugs are.

>> so why bother to mark any bug as blocking?
> Because it helps in management of a release.  It's a managerial tool.

Yes, of course. It's just that this particular bug is severe enough that it 
should be fixed before the next release. I'm even becoming to be inclined to 
think that it should be backported to the *previous* release, and I *hate* doing 
that sort of thing.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: release bugs [was Re: Processed: enriched.el code execution]
  2017-09-08  7:11               ` Paul Eggert
@ 2017-09-08  8:20                 ` Fabrice Popineau
  2017-09-08 21:42                   ` Óscar Fuentes
  2017-09-09 17:12                   ` Richard Stallman
  0 siblings, 2 replies; 19+ messages in thread
From: Fabrice Popineau @ 2017-09-08  8:20 UTC (permalink / raw)
  To: Paul Eggert; +Cc: rgm, Eli Zaretskii, Emacs developers

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

Maybe I am naive, but I don't see why a bug existing in previous releases
should be blocking.
If the bug exists in say emacs 25.1, blocking the release of 26.1 will not
prevent
people to be at risk because they will continue to use 25.1.
I would say that only newly introduced bugs for example related to new
features or refactoring
should be considered to be blocking.

Fabrice



2017-09-08 9:11 GMT+02:00 Paul Eggert <eggert@cs.ucla.edu>:

> Eli Zaretskii wrote:
>
>> marking bugs as blocking and their
>> urgency are two different and almost independent issues.
>>
>
> They are different but not that independent. Urgent bugs are considerably
> more likely to be blocking (i.e., they should be fixed before the next
> release) than non-urgent bugs are.
>
> so why bother to mark any bug as blocking?
>>>
>> Because it helps in management of a release.  It's a managerial tool.
>>
>
> Yes, of course. It's just that this particular bug is severe enough that
> it should be fixed before the next release. I'm even becoming to be
> inclined to think that it should be backported to the *previous* release,
> and I *hate* doing that sort of thing.
>
>


-- 
Fabrice Popineau
-----------------------------
CentraleSupelec
Département Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212
------------------------------

[-- Attachment #2: Type: text/html, Size: 2757 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: release bugs [was Re: Processed: enriched.el code execution]
  2017-09-08  8:20                 ` Fabrice Popineau
@ 2017-09-08 21:42                   ` Óscar Fuentes
  2017-09-09 17:12                   ` Richard Stallman
  1 sibling, 0 replies; 19+ messages in thread
From: Óscar Fuentes @ 2017-09-08 21:42 UTC (permalink / raw)
  To: Emacs developers

Fabrice Popineau <fabrice.popineau@centralesupelec.fr> writes:

> Maybe I am naive, but I don't see why a bug existing in previous releases
> should be blocking.

We opened a secret door that can be used to cause harm to our users. It is
bad enough that we did that on past releases, but it would be totally
irresponsible to not fix our blunder on the next release.

> If the bug exists in say emacs 25.1, blocking the release of 26.1 will not
> prevent
> people to be at risk because they will continue to use 25.1.

This is why I'm with Paul about backporting the fix. This bug is truly
abhorrent.

[snip]



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: release bugs [was Re: Processed: enriched.el code execution]
  2017-09-08  8:20                 ` Fabrice Popineau
  2017-09-08 21:42                   ` Óscar Fuentes
@ 2017-09-09 17:12                   ` Richard Stallman
  2017-09-09 18:27                     ` Fabrice Popineau
  1 sibling, 1 reply; 19+ messages in thread
From: Richard Stallman @ 2017-09-09 17:12 UTC (permalink / raw)
  To: Fabrice Popineau; +Cc: rgm, eliz, eggert, emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Maybe I am naive, but I don't see why a bug existing in previous releases
  > should be blocking.

Because this bug is so grave we must not tolerate its presence.

  > If the bug exists in say emacs 25.1, blocking the release of 26.1 will not
  > prevent
  > people to be at risk because they will continue to use 25.1.

We should urge them all to upgrade to the new Emacs 25 release that
we should make as soon as we can.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: release bugs [was Re: Processed: enriched.el code execution]
  2017-09-09 17:12                   ` Richard Stallman
@ 2017-09-09 18:27                     ` Fabrice Popineau
  0 siblings, 0 replies; 19+ messages in thread
From: Fabrice Popineau @ 2017-09-09 18:27 UTC (permalink / raw)
  To: rms; +Cc: rgm, Eli Zaretskii, Paul Eggert, Emacs developers

[-- Attachment #1: Type: text/plain, Size: 590 bytes --]

2017-09-09 19:12 GMT+02:00 Richard Stallman <rms@gnu.org>:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > Maybe I am naive, but I don't see why a bug existing in previous
> releases
>   > should be blocking.
>
> Because this bug is so grave we must not tolerate its presence.
>

I agree.
So I realized in the mean time that it all depends about the extension you
give to the  "blocking" term :-)

-- 
Fabrice

[-- Attachment #2: Type: text/html, Size: 1179 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2017-09-09 18:27 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <83tw0h0yem.fsf@gnu.org>
     [not found] ` <handler.s.C.150463767313430.transcript@debbugs.gnu.org>
2017-09-06  6:40   ` release bugs [was Re: Processed: enriched.el code execution] Glenn Morris
2017-09-06  9:41     ` John Wiegley
2017-09-06 10:00       ` Sven Joachim
2017-09-06 10:13         ` John Wiegley
2017-09-07  4:03         ` Richard Stallman
2017-09-07 14:43           ` Eli Zaretskii
2017-09-06 16:12     ` Eli Zaretskii
2017-09-07  6:30       ` Paul Eggert
2017-09-07 13:11         ` John Wiegley
2017-09-07 15:03         ` Eli Zaretskii
2017-09-07 21:32           ` Paul Eggert
2017-09-08  6:55             ` Eli Zaretskii
2017-09-08  7:11               ` Paul Eggert
2017-09-08  8:20                 ` Fabrice Popineau
2017-09-08 21:42                   ` Óscar Fuentes
2017-09-09 17:12                   ` Richard Stallman
2017-09-09 18:27                     ` Fabrice Popineau
2017-09-07 20:47         ` enriched.el code execution Reiner Steib
2017-09-07 21:24           ` Paul Eggert

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.