release bugs [was Re: Processed: enriched.el code execution]

release bugs [was Re: Processed: enriched.el code execution]

[Glenn Morris]

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

Re: release bugs [was Re: Processed: enriched.el code execution]

[John Wiegley]

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

Re: release bugs [was Re: Processed: enriched.el code execution]

[Sven Joachim]

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

Re: release bugs [was Re: Processed: enriched.el code execution]

[John Wiegley]

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

Re: release bugs [was Re: Processed: enriched.el code execution]

[Richard Stallman]

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

Re: release bugs [was Re: Processed: enriched.el code execution]

[Eli Zaretskii]

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

Re: release bugs [was Re: Processed: enriched.el code execution]

[Eli Zaretskii]

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

Re: release bugs [was Re: Processed: enriched.el code execution]

[Paul Eggert]

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.

Re: release bugs [was Re: Processed: enriched.el code execution]

[John Wiegley]

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

Re: release bugs [was Re: Processed: enriched.el code execution]

[Eli Zaretskii]

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

Re: release bugs [was Re: Processed: enriched.el code execution]

[Paul Eggert]

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

Re: release bugs [was Re: Processed: enriched.el code execution]

[Eli Zaretskii]

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

Re: release bugs [was Re: Processed: enriched.el code execution]

[Paul Eggert]

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.

Re: release bugs [was Re: Processed: enriched.el code execution]

[Fabrice Popineau]

[-- 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 --]

Re: release bugs [was Re: Processed: enriched.el code execution]

[Óscar Fuentes]

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]

Re: release bugs [was Re: Processed: enriched.el code execution]

[Richard Stallman]

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

Re: release bugs [was Re: Processed: enriched.el code execution]

[Fabrice Popineau]

[-- 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 --]

Re: enriched.el code execution

[Reiner Steib]

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.

Re: enriched.el code execution

[Paul Eggert]

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.