[ANNOUNCE] Emacs 25.3 released

[ANNOUNCE] Emacs 25.3 released

[Nicolas Petton]

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

Hi!

Version 25.3 of the Emacs text editor is now available.

For more information on Emacs, see:
  http://www.gnu.org/software/emacs

You can retrieve the source from your nearest GNU mirror by using one
of the following links:
  http://ftpmirror.gnu.org/emacs/emacs-25.3.tar.xz
  http://ftpmirror.gnu.org/emacs/emacs-25.3.tar.gz

You can get the PGP signatures at
  http://ftp.gnu.org/gnu/emacs/emacs-25.3.tar.xz.sig
  http://ftp.gnu.org/gnu/emacs/emacs-25.3.tar.gz.sig

You can choose a mirror explicitly from the list at:
  http://www.gnu.org/prep/ftp.html

Mirrors may take some time to update; the main GNU ftp server is at:
  http://ftp.gnu.org/gnu/emacs/

This is an emergency release to fix a security vulnerability in Emacs.

Enriched Text mode has its support for decoding 'x-display' disabled.
This feature allows saving 'display' properties as part of text.
Emacs 'display' properties support evaluation of arbitrary Lisp forms
as part of instantiating the property, so decoding 'x-display' is
vulnerable to executing arbitrary malicious Lisp code included in the
text (e.g., sent as part of an email message).

This vulnerability was introduced in Emacs 19.29.  To work around that
in Emacs versions before 25.3, append the following to your ~/.emacs
init file:

  (eval-after-load "enriched"
    '(defun enriched-decode-display-prop (start end &optional param)
       (list start end)))

Gnus no longer supports "richtext" and "enriched" inline MIME objects.
This support was disabled to avoid evaluation of arbitrary Lisp code
contained in email messages and news articles.


Printed copies of the Emacs manual are available for purchase from the
Free Software Foundation's online store at:
  http://shop.fsf.org/product/emacs-manual/

(The version on sale is updated for Emacs 24.2, but it remains a great
reference book for current Emacs, and buying a copy is a great way to
support the work of the FSF.)

Regards,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ANNOUNCE] Emacs 25.3 released

[Andreas Schwab]

On Sep 11 2017, Nicolas Petton <nicolas@petton.fr> wrote:

> Version 25.3 of the Emacs text editor is now available.

The release has not been tagged.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [ANNOUNCE] Emacs 25.3 released

[Nicolas Petton]

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

Andreas Schwab <schwab@suse.de> writes:

> The release has not been tagged.

No, as there's no corresponding git commit yet.  Same for the website,
it needs to be updated (I'll do that now).

Cheers,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ANNOUNCE] Emacs 25.3 released

[Andreas Schwab]

On Sep 12 2017, Nicolas Petton <nicolas@petton.fr> wrote:

> Andreas Schwab <schwab@suse.de> writes:
>
>> The release has not been tagged.
>
> No, as there's no corresponding git commit yet.

Why not?  A release should never be make out of the blue.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [ANNOUNCE] Emacs 25.3 released

[Rostislav Svoboda]

>>> The release has not been tagged.
>>
>> No, as there's no corresponding git commit yet.

???
That would mean the Emacs 25.3 is almost open source.
Except the last commit containing [dramatic pause] we don't know what!?!

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

On September 12, 2017 3:10:00 PM GMT+03:00, Rostislav Svoboda <rostislav.svoboda@gmail.com> wrote:
> >>> The release has not been tagged.
> >>
> >> No, as there's no corresponding git commit yet.
> 
> ???
> That would mean the Emacs 25.3 is almost open source.
> Except the last commit containing [dramatic pause] we don't know
> what!?!

Please calm down, no catastrophe happened.

Desperate times call for desperate measures.  It was my
judgment call.

Re: [ANNOUNCE] Emacs 25.3 released

[Clément Pit-Claudel]

On 2017-09-12 14:10, Rostislav Svoboda wrote:
> ???
> That would mean the Emacs 25.3 is almost open source.
> Except the last commit containing [dramatic pause] we don't know what!?!

What are you talking about? The message you're replying to points to a source tarball.

Re: [ANNOUNCE] Emacs 25.3 released

[Nicolas Petton]

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

Rostislav Svoboda <rostislav.svoboda@gmail.com> writes:

>>>> The release has not been tagged.
>>>
>>> No, as there's no corresponding git commit yet.
>
> ???
> That would mean the Emacs 25.3 is almost open source.

There will be a git commit and a 25.3 tag, no worries.  The tarball was
built in a hurry.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ANNOUNCE] Emacs 25.3 released

[Andreas Schwab]

On Sep 12 2017, Nicolas Petton <nicolas@petton.fr> wrote:

> There will be a git commit and a 25.3 tag, no worries.  The tarball was
> built in a hurry.

There should never be a hurry.  Ever.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [ANNOUNCE] Emacs 25.3 released

[Rostislav Svoboda]

>>> The release has not been tagged.
>>
>> No, as there's no corresponding git commit yet.

The thing is guys in my daily-job I do this kind of "release and pray"
source code management on a daily basis.
You know - cobol, mainframes, finance industry, dinosaurs...

I get restless pretty quickly when I spot the Cthulhu in the open source world.

> There should never be a hurry.  Ever.

2017-09-12 15:03 GMT+02:00 Andreas Schwab <schwab@suse.de>:
> There should never be a hurry.  Ever.

Thank you Andreas.

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> From: Rostislav Svoboda <rostislav.svoboda@gmail.com>
> Date: Tue, 12 Sep 2017 15:29:53 +0200
> Cc: Nicolas Petton <nicolas@petton.fr>, Emacs Devel <emacs-devel@gnu.org>
> 
> >>> The release has not been tagged.
> >>
> >> No, as there's no corresponding git commit yet.
> 
> The thing is guys in my daily-job I do this kind of "release and pray"
> source code management on a daily basis.

Maybe _you_ do that, but Nicolas didn't.  He did all his work from a
Git branch, with full source control.

> I get restless pretty quickly when I spot the Cthulhu in the open source world.

Emacs is not open source.

Re: [ANNOUNCE] Emacs 25.3 released

[Andreas Schwab]

On Sep 12 2017, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Rostislav Svoboda <rostislav.svoboda@gmail.com>
>> Date: Tue, 12 Sep 2017 15:29:53 +0200
>> Cc: Nicolas Petton <nicolas@petton.fr>, Emacs Devel <emacs-devel@gnu.org>
>> 
>> >>> The release has not been tagged.
>> >>
>> >> No, as there's no corresponding git commit yet.
>> 
>> The thing is guys in my daily-job I do this kind of "release and pray"
>> source code management on a daily basis.
>
> Maybe _you_ do that, but Nicolas didn't.  He did all his work from a
> Git branch, with full source control.

I don't see any branch containing the release.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [ANNOUNCE] Emacs 25.3 released

[Paul Eggert]

On 09/12/2017 08:48 AM, Andreas Schwab wrote:
> I don't see any branch containing the release.

Nor do I. I was thinking of creating an emacs-25.3 branch post facto, 
with a single commit representing the release, and tagged as emacs-25.3. 
However, it'd be better if Nicolas did it, since I presume he already 
has a branch in his private repository. If he doesn't have such a 
branch, I'll volunteer to create emacs-25.3 as described.

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> Cc: nicolas@petton.fr, Rostislav Svoboda <rostislav.svoboda@gmail.com>,
>  emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 12 Sep 2017 08:55:34 -0700
> 
> On 09/12/2017 08:48 AM, Andreas Schwab wrote:
> > I don't see any branch containing the release.
> 
> Nor do I. I was thinking of creating an emacs-25.3 branch post facto, 
> with a single commit representing the release, and tagged as emacs-25.3. 

That's what will be done.

Re: [ANNOUNCE] Emacs 25.3 released

[Nicolas Petton]

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

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

> Nor do I. I was thinking of creating an emacs-25.3 branch post facto, 
> with a single commit representing the release, and tagged as emacs-25.3. 
> However, it'd be better if Nicolas did it, since I presume he already 
> has a branch in his private repository.

I do have the changes in my local repository, I'll make the emacs-25.3
branch.

Cheers,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ANNOUNCE] Emacs 25.3 released

[Nicolas Petton]

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

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

> Nor do I. I was thinking of creating an emacs-25.3 branch post facto, 
> with a single commit representing the release, and tagged as
> emacs-25.3.

I have pushed commit bd299e7 in a new emacs-25.3 branch, as well as a
tag.

Cheers,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: Rostislav Svoboda <rostislav.svoboda@gmail.com>,  nicolas@petton.fr,  emacs-devel@gnu.org
> Date: Tue, 12 Sep 2017 17:48:22 +0200
> 
> > Maybe _you_ do that, but Nicolas didn't.  He did all his work from a
> > Git branch, with full source control.
> 
> I don't see any branch containing the release.

Do you have access to Nicolas's machine?

Re: [ANNOUNCE] Emacs 25.3 released

[Nicolas Petton]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> I don't see any branch containing the release.
>
> Do you have access to Nicolas's machine?

I certainly hope not :-D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ANNOUNCE] Emacs 25.3 released

[Andreas Schwab]

On Sep 12 2017, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Andreas Schwab <schwab@suse.de>
>> Cc: Rostislav Svoboda <rostislav.svoboda@gmail.com>,  nicolas@petton.fr,  emacs-devel@gnu.org
>> Date: Tue, 12 Sep 2017 17:48:22 +0200
>> 
>> > Maybe _you_ do that, but Nicolas didn't.  He did all his work from a
>> > Git branch, with full source control.
>> 
>> I don't see any branch containing the release.
>
> Do you have access to Nicolas's machine?

Neither do you.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [ANNOUNCE] Emacs 25.3 released

[Rostislav Svoboda]

2017-09-12 17:25 GMT+02:00 Eli Zaretskii <eliz@gnu.org>:
> Emacs is not open source.

???

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> From: Rostislav Svoboda <rostislav.svoboda@gmail.com>
> Date: Tue, 12 Sep 2017 18:42:24 +0200
> Cc: Andreas Schwab <schwab@suse.de>, Nicolas Petton <nicolas@petton.fr>, 
> 	"emacs-devel@gnu.org Development" <emacs-devel@gnu.org>
> 
> 2017-09-12 17:25 GMT+02:00 Eli Zaretskii <eliz@gnu.org>:
> > Emacs is not open source.
> 
> ???

  https://www.gnu.org/philosophy/free-software-for-freedom.en.html

Re: [ANNOUNCE] Emacs 25.3 released

[Nicolas Petton]

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

Rostislav Svoboda <rostislav.svoboda@gmail.com> writes:

> The thing is guys in my daily-job I do this kind of "release and pray"
> source code management on a daily basis.
> You know - cobol, mainframes, finance industry, dinosaurs...

I had to produce the tarball as quickly as I could, which meant
yesterday evening after work.  We agreed with Eli not to bother with the
website or the Git branch, as it was much less urgent than releasing the
security fix.  However, I do have the changes on my local Git repo, so
there's no need to worry (I'll push them right after sending this email).

To be honest, I'm a bit frustrated with all the negative attitude
regarding this release.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> From: Nicolas Petton <nicolas@petton.fr>
> Cc: Emacs Devel <emacs-devel@gnu.org>, eliz@gnu.org
> Date: Tue, 12 Sep 2017 20:38:49 +0200
> 
> To be honest, I'm a bit frustrated with all the negative attitude
> regarding this release.

Me too.  And I appreciate your hard and accurate work very much.
Thanks!

Re: [ANNOUNCE] Emacs 25.3 released

[Robert Weiner]

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

On Tue, Sep 12, 2017 at 2:38 PM, Nicolas Petton <nicolas@petton.fr> wrote:

>
> To be honest, I'm a bit frustrated with all the negative attitude
> regarding this release.
>

​Don't worry about it.  Everyone knows you are doing a great job for Emacs
as are the other major contributors.
As Eli said, there will always be noise and questions.  Your legacy will be
in the releases made.

Bob

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

Re: [ANNOUNCE] Emacs 25.3 released

[martin rudalics]

 > To be honest, I'm a bit frustrated with all the negative attitude
 > regarding this release.

Perfectly done IMHO (I'm afraid this won't relieve your frustration
though).

Many thanks, martin

Re: [ANNOUNCE] Emacs 25.3 released

[Rostislav Svoboda]

> To be honest, I'm a bit frustrated with all the negative attitude
> regarding this release.

Don't worry too much about it Nico.
For our part this might one of the bicycle shedding situations.
I think sometimes we should really be more grateful for your work...

Re: [ANNOUNCE] Emacs 25.3 released

[Clément Pit-Claudel]

On 2017-09-12 20:38, Nicolas Petton wrote:
> Rostislav Svoboda <rostislav.svoboda@gmail.com> writes:
> 
>> The thing is guys in my daily-job I do this kind of "release and pray"
>> source code management on a daily basis.
>> You know - cobol, mainframes, finance industry, dinosaurs...
> 
> I had to produce the tarball as quickly as I could, which meant
> yesterday evening after work.  We agreed with Eli not to bother with the
> website or the Git branch, as it was much less urgent than releasing the
> security fix.  However, I do have the changes on my local Git repo, so
> there's no need to worry (I'll push them right after sending this email).
> 
> To be honest, I'm a bit frustrated with all the negative attitude
> regarding this release.
> 
> Nico

I think you did great work.
Thanks for your hard work and your commitment!

Clément.

Re: [ANNOUNCE] Emacs 25.3 released

[Tino Calancha]

On Tue, 12 Sep 2017, Nicolas Petton wrote:

> To be honest, I'm a bit frustrated with all the negative attitude
> regarding this release.
>
> Nico
Excellent job, very appreciated from my location.
Thank you very much!
Tino

Re: [ANNOUNCE] Emacs 25.3 released

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

  > To be honest, I'm a bit frustrated with all the negative attitude
  > regarding this release.

The people who understand the issue appreciate that what you did was
fine.

-- 
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: [ANNOUNCE] Emacs 25.3 released

[Tim Cross]

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

Hi Nicolas,

it is very easy to be a critic and technology has just made it easy to
spread those criticisms with no real cost - just type and hit send. As far
as I can see, you and Eli thought about how to do this release, considered
the implications and did what you believed was most appropriate given
priorities and resources. I certainly acknowledge and appreciate your
efforts. Ignore the negative noise, most of it is lacking in facts, built
on assumptions and fails to recognise hindsight is always 20/20. Thee has
been no adverse consequences and I feel you and Eli have shown the action
was responsible and well reasoned. Points have been raised and
acknowledged, time to move on and recognise that most of the fine work done
to maintain Emacs is done by volunteers who need to make time to do these
contributions in a modern world where most of us have too much to do with
too little time to do it.

thanks for your efforts.

Tim


On 13 September 2017 at 04:38, Nicolas Petton <nicolas@petton.fr> wrote:

> Rostislav Svoboda <rostislav.svoboda@gmail.com> writes:
>
> > The thing is guys in my daily-job I do this kind of "release and pray"
> > source code management on a daily basis.
> > You know - cobol, mainframes, finance industry, dinosaurs...
>
> I had to produce the tarball as quickly as I could, which meant
> yesterday evening after work.  We agreed with Eli not to bother with the
> website or the Git branch, as it was much less urgent than releasing the
> security fix.  However, I do have the changes on my local Git repo, so
> there's no need to worry (I'll push them right after sending this email).
>
> To be honest, I'm a bit frustrated with all the negative attitude
> regarding this release.
>
> Nico
>



-- 
regards,

Tim

--
Tim Cross

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

Re: [ANNOUNCE] Emacs 25.3 released

[Richard Copley]

Unfortunately, the release seems not to work on 64-bit Windows 7. See:
<http://lists.gnu.org/archive/html/help-gnu-emacs/2017-09/msg00150.html>

Windows users remaining on 25.2 may not be a security problem per se,
as the rules for linking directories are different there AIUI, but that question
should be considered by the experts here.

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Thu, 21 Sep 2017 08:25:31 +0100
> 
> Unfortunately, the release seems not to work on 64-bit Windows 7. See:
> <http://lists.gnu.org/archive/html/help-gnu-emacs/2017-09/msg00150.html>

That's slightly inaccurate: the 25.3 release does work on Windows 7,
it's just that the specific 64-bit binaries uploaded to the GNU FTP
site don't.

I'd suggest to upload fixed binaries.

Re: [ANNOUNCE] Emacs 25.3 released

[Richard Copley]

On 21 September 2017 at 08:56, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Thu, 21 Sep 2017 08:25:31 +0100
>>
>> Unfortunately, the release seems not to work on 64-bit Windows 7. See:
>> <http://lists.gnu.org/archive/html/help-gnu-emacs/2017-09/msg00150.html>
>
> That's slightly inaccurate: the 25.3 release does work on Windows 7,
> it's just that the specific 64-bit binaries uploaded to the GNU FTP
> site don't.
>
> I'd suggest to upload fixed binaries.

To do that without creating a new release, of course, means using a
toolchain version other than that which the excellent Nico in fact
used.

FYI the MSYS2 package sources don't provide old versions of packages.
Their currently available MinGW-W64 toolchains won't build a 64-bit
Emacs that works on Windows 7 from the 25.3 release.

Will the mingw.org toolchains described in nt/INSTALL do it?

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Thu, 21 Sep 2017 19:53:42 +0100
> Cc: Emacs Development <emacs-devel@gnu.org>
> 
> > I'd suggest to upload fixed binaries.
> 
> To do that without creating a new release, of course, means using a
> toolchain version other than that which the excellent Nico in fact
> used.

No, it means to backport the change in the library order and then
rebuild.  The modified source tarball should be uploaded to the same
place.

> FYI the MSYS2 package sources don't provide old versions of packages.
> Their currently available MinGW-W64 toolchains won't build a 64-bit
> Emacs that works on Windows 7 from the 25.3 release.

I think the binary will work on Windows 7 if built on Windows 7.  But
I don't suggest actually trying that.

> Will the mingw.org toolchains described in nt/INSTALL do it?

Not for a 64-bit build, no.

Re: [ANNOUNCE] Emacs 25.3 released

[Richard Copley]

On 21 September 2017 at 20:15, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Thu, 21 Sep 2017 19:53:42 +0100
>> Cc: Emacs Development <emacs-devel@gnu.org>
>>
>> > I'd suggest to upload fixed binaries.
>>
>> To do that without creating a new release, of course, means using a
>> toolchain version other than that which the excellent Nico in fact
>> used.
>
> No, it means to backport the change in the library order and then
> rebuild.  The modified source tarball should be uploaded to the same
> place.

Great.

>> FYI the MSYS2 package sources don't provide old versions of packages.
>> Their currently available MinGW-W64 toolchains won't build a 64-bit
>> Emacs that works on Windows 7 from the 25.3 release.
>
> I think the binary will work on Windows 7 if built on Windows 7.  But
> I don't suggest actually trying that.

#28493.

>> Will the mingw.org toolchains described in nt/INSTALL do it?
>
> Not for a 64-bit build, no.

OK, thanks.

Re: [ANNOUNCE] Emacs 25.3 released

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard Copley <rcopley@gmail.com>
>> Date: Thu, 21 Sep 2017 19:53:42 +0100
>> Cc: Emacs Development <emacs-devel@gnu.org>
>> 
>> > I'd suggest to upload fixed binaries.
>> 
>> To do that without creating a new release, of course, means using a
>> toolchain version other than that which the excellent Nico in fact
>> used.
>
> No, it means to backport the change in the library order and then
> rebuild.  The modified source tarball should be uploaded to the same
> place.

It's possible, or possibly a new binary and a patch file for the source?

But it all sounds like a release to me. Would Emacs-25.3.1 not be
better?

We talking about 7b3d1c6beb54ef6c423a9?

Phil

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: Richard Copley <rcopley@gmail.com>,  emacs-devel@gnu.org
> Date: Thu, 21 Sep 2017 21:56:27 +0100
> 
> > No, it means to backport the change in the library order and then
> > rebuild.  The modified source tarball should be uploaded to the same
> > place.
> 
> It's possible, or possibly a new binary and a patch file for the source?

I'm not sure a patch file is enough to abide by the GPL.  Is there a
problem to upload a full tarball?

> But it all sounds like a release to me. Would Emacs-25.3.1 not be
> better?

Yes, 25.3.1 would be better.  But I'd also add a special README to
explain what it is.  And I think I'd remove the 25.3 zip files, as
they are not very useful.

> We talking about 7b3d1c6beb54ef6c423a9?

Yes.

Re: [ANNOUNCE] Emacs 25.3 released

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

  > > It's possible, or possibly a new binary and a patch file for the source?

  > I'm not sure a patch file is enough to abide by the GPL.  Is there a
  > problem to upload a full tarball?

Please do it the clean way: make a self-contained correct release,
not a patch.

-- 
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: [ANNOUNCE] Emacs 25.3 released

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Cc: Richard Copley <rcopley@gmail.com>,  emacs-devel@gnu.org
>> Date: Thu, 21 Sep 2017 21:56:27 +0100
>> 
>> > No, it means to backport the change in the library order and then
>> > rebuild.  The modified source tarball should be uploaded to the same
>> > place.
>> 
>> It's possible, or possibly a new binary and a patch file for the source?
>
> I'm not sure a patch file is enough to abide by the GPL.  Is there a
> problem to upload a full tarball?
>
>> But it all sounds like a release to me. Would Emacs-25.3.1 not be
>> better?
>
> Yes, 25.3.1 would be better.  But I'd also add a special README to
> explain what it is.  And I think I'd remove the 25.3 zip files, as
> they are not very useful.
>
>> We talking about 7b3d1c6beb54ef6c423a9?
>
> Yes.


I have uploaded a patched 25.3 to alpha and would welcome testing (esp
on Windows 7).

Issues: this is not a full release, it's just a patched
25.3. Directories have been left as 25.3. And I did the patch by hand,
because I couldn't get git to work.

Not sure if this the best way; a full 25.3.1 release might be
better. However, it would be functionality identical to 25.3 for most
systems, and I'd need Nico to do the release, as I never have done one.

Phil

Re: [ANNOUNCE] Emacs 25.3 released

[Stephen Leake]

phillip.lord@russet.org.uk (Phillip Lord) writes:

> I have uploaded a patched 25.3 to alpha and would welcome testing (esp
> on Windows 7).

emacs-25.3_1-x86_64.zip works for me on Windows 8


-- 
-- Stephe

Re: [ANNOUNCE] Emacs 25.3 released

[Phillip Lord]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> phillip.lord@russet.org.uk (Phillip Lord) writes:
>
>> I have uploaded a patched 25.3 to alpha and would welcome testing (esp
>> on Windows 7).
>
> emacs-25.3_1-x86_64.zip works for me on Windows 8


Thanks

Did the old zip fail?

Re: [ANNOUNCE] Emacs 25.3 released

[Richard Copley]

On 29 September 2017 at 11:46, Phillip Lord <phillip.lord@russet.org.uk> wrote:
> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> phillip.lord@russet.org.uk (Phillip Lord) writes:
>>
>>> I have uploaded a patched 25.3 to alpha and would welcome testing (esp
>>> on Windows 7).
>>
>> emacs-25.3_1-x86_64.zip works for me on Windows 8
>
>
> Thanks
>
> Did the old zip fail?

Confirm that for me on Windows 7,
* the old zip fails (same error as discussed on the Help list) and
* the new alpha 25.3_1 zip works.

Many thanks Phillip. Sorry, I didn't see your email until Stephen's reply.

Re: [ANNOUNCE] Emacs 25.3 released

[Phillip Lord]

Richard Copley <rcopley@gmail.com> writes:

> On 29 September 2017 at 11:46, Phillip Lord <phillip.lord@russet.org.uk> wrote:
>> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>>
>>> phillip.lord@russet.org.uk (Phillip Lord) writes:
>>>
>>>> I have uploaded a patched 25.3 to alpha and would welcome testing (esp
>>>> on Windows 7).
>>>
>>> emacs-25.3_1-x86_64.zip works for me on Windows 8
>>
>>
>> Thanks
>>
>> Did the old zip fail?
>
> Confirm that for me on Windows 7,
> * the old zip fails (same error as discussed on the Help list) and
> * the new alpha 25.3_1 zip works.
>
> Many thanks Phillip. Sorry, I didn't see your email until Stephen's reply.


Thanks very much for the positive test.

I'll upload as soon as I can. For the next release, I'll send a specific
email to emacs-devel asking for testers before I full release the
binaries.

Phil

Re: [ANNOUNCE] Emacs 25.3 released

[Stephen Leake]

phillip.lord@russet.org.uk (Phillip Lord) writes:

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> phillip.lord@russet.org.uk (Phillip Lord) writes:
>>
>>> I have uploaded a patched 25.3 to alpha and would welcome testing (esp
>>> on Windows 7).
>>
>> emacs-25.3_1-x86_64.zip works for me on Windows 8
>
>
> Thanks
>
> Did the old zip fail?

I never tried it; I only tried 25.1
>

-- 
-- Stephe

Re: [ANNOUNCE] Emacs 25.3 released

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard Copley <rcopley@gmail.com>
>> Date: Thu, 21 Sep 2017 08:25:31 +0100
>> 
>> Unfortunately, the release seems not to work on 64-bit Windows 7. See:
>> <http://lists.gnu.org/archive/html/help-gnu-emacs/2017-09/msg00150.html>
>
> That's slightly inaccurate: the 25.3 release does work on Windows 7,
> it's just that the specific 64-bit binaries uploaded to the GNU FTP
> site don't.
>
> I'd suggest to upload fixed binaries.

I don't know how to do this. I have upgraded by system and I do not know
how to downgrade it. Even if I did, I am afraid, I didn't think to
record the update times, so I don't know how to downgrade it to.

Unfortunately, the best that I can currently do in terms of testing is
simply to run the binaries I create and see if they work. I try and test
them on a different machine, but I no have access to only 2 windows
machines and both of them use the same version of windows.

Perhaps, I should start uploading binaries to alpha.gnu.org for a few
days, before moving them to release; this would be the second set of
binaries to have an issue in this cycle.

Phil

Re: [ANNOUNCE] Emacs 25.3 released

[Stephen Leake]

phillip.lord@russet.org.uk (Phillip Lord) writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Richard Copley <rcopley@gmail.com>
>>> Date: Thu, 21 Sep 2017 08:25:31 +0100
>>> 
>>> Unfortunately, the release seems not to work on 64-bit Windows 7. See:
>>> <http://lists.gnu.org/archive/html/help-gnu-emacs/2017-09/msg00150.html>
>>
>> That's slightly inaccurate: the 25.3 release does work on Windows 7,
>> it's just that the specific 64-bit binaries uploaded to the GNU FTP
>> site don't.
>>
>> I'd suggest to upload fixed binaries.
>
> I don't know how to do this. I have upgraded by system and I do not know
> how to downgrade it. Even if I did, I am afraid, I didn't think to
> record the update times, so I don't know how to downgrade it to.
>
> Unfortunately, the best that I can currently do in terms of testing is
> simply to run the binaries I create and see if they work. I try and test
> them on a different machine, but I no have access to only 2 windows
> machines and both of them use the same version of windows.
>
> Perhaps, I should start uploading binaries to alpha.gnu.org for a few
> days, before moving them to release; this would be the second set of
> binaries to have an issue in this cycle.

+1; I can test those, on Windows 8.

-- 
-- Stephe

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Date: Thu, 21 Sep 2017 21:37:48 +0100
> Cc: Richard Copley <rcopley@gmail.com>, emacs-devel@gnu.org
> 
> Perhaps, I should start uploading binaries to alpha.gnu.org for a few
> days, before moving them to release; this would be the second set of
> binaries to have an issue in this cycle.

That's normally done, AFAIK, but for an emergency release it would be
good to be able to avoid an extra upload to a different place.

I don't think we should canonicalize a solution to this particular
problem.  It is quite unique.  I knew about the issue for a few years,
but never suspected a back-stab from MinGW import libraries.  Chances
for this scenario to repeat itself are quite slim.  The only amendment
to our procedures that I'd suggest to consider is to ask a couple of
people to unpack and run the binary on various versions of Windows
once it's uploaded.  This is what Nicolas did with the source tarball,
after uploading it to the GNU FTP site.

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Date: Tue, 12 Sep 2017 15:03:16 +0200
> Cc: Rostislav Svoboda <rostislav.svoboda@gmail.com>,
> 	Emacs Devel <emacs-devel@gnu.org>
> 
> On Sep 12 2017, Nicolas Petton <nicolas@petton.fr> wrote:
> 
> > There will be a git commit and a 25.3 tag, no worries.  The tarball was
> > built in a hurry.
> 
> There should never be a hurry.  Ever.

There should be no security vulnerabilities, either.  Ever.  But there
was, this time.  So we wanted to put the tarball out the door quickly
and safely, because that's what the community expected.

We should all thank Nicolas who did a splendid job, just a few hours
after I gave him the final patch.  There's no need to pounce on him or
make the (false) presentation of his job as less than perfect.

Re: [ANNOUNCE] Emacs 25.3 released

[Andreas Schwab]

On Sep 12 2017, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Andreas Schwab <schwab@suse.de>
>> Date: Tue, 12 Sep 2017 15:03:16 +0200
>> Cc: Rostislav Svoboda <rostislav.svoboda@gmail.com>,
>> 	Emacs Devel <emacs-devel@gnu.org>
>> 
>> On Sep 12 2017, Nicolas Petton <nicolas@petton.fr> wrote:
>> 
>> > There will be a git commit and a 25.3 tag, no worries.  The tarball was
>> > built in a hurry.
>> 
>> There should never be a hurry.  Ever.
>
> There should be no security vulnerabilities, either.  Ever.  But there
> was, this time.  So we wanted to put the tarball out the door quickly
> and safely, because that's what the community expected.

It was you who removed it from the blocking items?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: nicolas@petton.fr,  rostislav.svoboda@gmail.com,  emacs-devel@gnu.org
> Date: Tue, 12 Sep 2017 17:47:14 +0200
> 
> > There should be no security vulnerabilities, either.  Ever.  But there
> > was, this time.  So we wanted to put the tarball out the door quickly
> > and safely, because that's what the community expected.
> 
> It was you who removed it from the blocking items?

For Emacs 26.1, which is not what we are talking about here.

Re: [ANNOUNCE] Emacs 25.3 released

[Andreas Schwab]

On Sep 12 2017, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Andreas Schwab <schwab@suse.de>
>> Cc: nicolas@petton.fr,  rostislav.svoboda@gmail.com,  emacs-devel@gnu.org
>> Date: Tue, 12 Sep 2017 17:47:14 +0200
>> 
>> > There should be no security vulnerabilities, either.  Ever.  But there
>> > was, this time.  So we wanted to put the tarball out the door quickly
>> > and safely, because that's what the community expected.
>> 
>> It was you who removed it from the blocking items?
>
> For Emacs 26.1, which is not what we are talking about here.

It's the same thing.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [ANNOUNCE] Emacs 25.3 released

[Andreas Schwab]

It's all about trust.  And especially in the context of security, trust
is the most important thing.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [ANNOUNCE] Emacs 25.3 released

[Paul Eggert]

Andreas Schwab wrote:
> It's all about trust.  And especially in the context of security, trust
> is the most important thing.

You're right. Security-minded users need to be suspicious when new software 
releases are made out of the blue. Having an emergency release tagged and 
publicly visible in the repository can help allay these natural suspicions.

We don't have much practice making emergency Emacs releases because we don't 
often make them (which is a good thing!). That being said, the next time it 
happens we should try to have a smoother rollout, and having a properly tagged 
commit should be part of that. This will help avoid this particular confusion 
next time.

Another thing I'd like is a faster rollout. We were publicly notified of the bug 
on September 4 and did not announce a new release containing a small fix until 
over a week later. Although there were reasons for the delay, it would be better 
to get announcements and fixes out faster. I've had multiple offers from others 
to help, and would like to take up at least one of these offers. Of course trust 
is an important concern here as well.

Re: [ANNOUNCE] Emacs 25.3 released

[Nicolas Petton]

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

Andreas Schwab <schwab@suse.de> writes:

> It's all about trust.  And especially in the context of security, trust
> is the most important thing.

First, if I'm not being trusted with the release tarballs, somebody else
can build them next time.

Second, you can easily diff the emacs-25.3 tarball against emacs-25.2.

Even if I did create a branch and tag before publishing the tarball,
you'd have no guarantee that the tarball actually contains the content
of the git commit.  Diffing is the only way for you to see the actual
changes.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ANNOUNCE] Emacs 25.3 released

[Paul Eggert]

Nicolas Petton wrote:
> First, if I'm not being trusted with the release tarballs, somebody else
> can build them next time.
> 
> Second, you can easily diff the emacs-25.3 tarball against emacs-25.2.
> 
> Even if I did create a branch and tag before publishing the tarball,
> you'd have no guarantee that the tarball actually contains the content
> of the git commit.  Diffing is the only way for you to see the actual
> changes.

All quite true. Still, trust is typically established by multiple means. Many 
users won't have time to track down where the diff was published or to read the 
diff, or they won't have the technical ability to understand the diff's 
implications. And many users won't know who you are. But if these users trust 
savannah.gnu.org, a tagged commit there can be enough for them so that they 
don't have to do the other stuff. (And there may be some very cautious users who 
want to do all of the above....)

So it is helpful to have a tagged commit at the time of release, even though a 
tag by itself is not enough to satisfy the most-cautious, and even though many 
users don't care about the tag.

Some background here. I've managed releases for the public-domain time zone 
database (tzdb) for several years. Some of my correspondents there are *quite* 
cautious, way more cautious than anything mentioned in this thread. They have 
asked for multiple ways to verify that each release is what it purports to be, 
beyond what I thought was needed. But they're *users*. They know their needs 
better than I do. And if they say they want SHA-512 checksums in addition to GPG 
checksums, who am I to tell them that they're redundant? I want them to trust 
the tzdb distribution, so I try to accommodate their concerns, not to argue with 
them.

Re: [ANNOUNCE] Emacs 25.3 released

[Rostislav Svoboda]

I have a habit of building my emacs from the (git repo) source under GNU Linux.
Since I do it often (= everything is already installed & configured)
it's a simple:
    make; sudo make install
When looking at nt/README*, nt/INSTALL* I see it's a 1512 lines long story.
Could we make it shorter please?

@Nico: I guess you're most experienced one here - are these file up-to-date?

Thanx

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> From: Rostislav Svoboda <rostislav.svoboda@gmail.com>
> Date: Wed, 13 Sep 2017 10:57:09 +0200
> Cc: Nicolas Petton <nicolas@petton.fr>, Andreas Schwab <schwab@suse.de>, Eli Zaretskii <eliz@gnu.org>, 
> 	"emacs-devel@gnu.org Development" <emacs-devel@gnu.org>
> 
> When looking at nt/README*, nt/INSTALL* I see it's a 1512 lines long story.
> Could we make it shorter please?

(You do realize that nt/INSTALL is for building Emacs on MS-Windows,
yes?)

nt/INSTALL begins with a 27-line short description of the build
procedure.  All the rest explains how to set up the development
environment, where to find optional support libraries, etc. --
something that on Windows is not always trivial.  If you already have
figured out how to set up your build environment, you don't need to
read anything past those first 27 lines.

IOW, the rest of the 1500 lines have nothing to do with the build per
se.

> @Nico: I guess you're most experienced one here - are these file up-to-date?

They are.

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> From: Nicolas Petton <nicolas@petton.fr>
> Cc: rostislav.svoboda@gmail.com, emacs-devel@gnu.org
> Date: Wed, 13 Sep 2017 09:40:23 +0200
> 
> > It's all about trust.  And especially in the context of security, trust
> > is the most important thing.
> 
> First, if I'm not being trusted with the release tarballs, somebody else
> can build them next time.

I trust you, Nicolas.

An important aspect of free software that people tend to forget is
that whoever does the job gets to choose the tools, and as long as the
end result is good (and in this case it is more than that), that's
their prerogative.  Letting someone do important job, let alone
service to the community, and then criticizing them for the tools
they've chosen, is at least unfair.

Nicolas volunteered for the job when no one else would.  Let's be
grateful, and let's see the 99% full part of the glass.  If we don't
support our volunteers, we have no future.

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

On September 13, 2017 9:50:56 AM GMT+03:00, Andreas Schwab <schwab@suse.de> wrote:
> It's all about trust.  And especially in the context of security,
> trust
> is the most important thing.
> 
> Andreas.

The trust was never harmed, since the actual patch was posted
here, in advance.

Re: [ANNOUNCE] Emacs 25.3 released

[Andreas Schwab]

On Sep 13 2017, Eli Zaretskii <eliz@gnu.org> wrote:

> The trust was never harmed, since the actual patch was posted
> here, in advance.

Everyone has to do his own assessment about trust.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

On September 13, 2017 11:27:51 AM GMT+03:00, Andreas Schwab <schwab@suse.de> wrote:
> On Sep 13 2017, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > The trust was never harmed, since the actual patch was posted
> > here, in advance.
> 
> Everyone has to do his own assessment about trust.
> 
> Andreas.

The full source is in the tarball, and the change was posted in advance.
How can a Git branch increase the trust is beyond me.

This certainly smells of NIH etc.

Re: [ANNOUNCE] Emacs 25.3 released

[Andreas Schwab]

On Sep 13 2017, Eli Zaretskii <eliz@gnu.org> wrote:

> The full source is in the tarball, and the change was posted in advance.
> How can a Git branch increase the trust is beyond me.
>
> This certainly smells of NIH etc.

It's about ignoring best practices.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: emacs-devel@gnu.org,  nicolas@petton.fr, rostislav.svoboda@gmail.com
> Date: Wed, 13 Sep 2017 10:48:49 +0200
> 
> On Sep 13 2017, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > The full source is in the tarball, and the change was posted in advance.
> > How can a Git branch increase the trust is beyond me.
> >
> > This certainly smells of NIH etc.
> 
> It's about ignoring best practices.

They were not ignored.  And we don't have "best practices" for such a
contingency, at least not yet.

Re: [ANNOUNCE] Emacs 25.3 released

[Mike Gerwitz]

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

On Wed, Sep 13, 2017 at 11:42:05 +0300, Eli Zaretskii wrote:
> The full source is in the tarball, and the change was posted in advance.
> How can a Git branch increase the trust is beyond me.
>
> This certainly smells of NIH etc.

Also, the tarball was uploaded to ftp.gnu.org, and signed.  Uploading to
ftp.gnu.org itself requires the request to be signed with a GPG key
registered on Savannah.[0]  This level of security is greater and more
formal than repository commits/tags.

If someone's system were compromised to the point of being able to
successfully upload to ftp.gnu.org, chances are that they'll be able to
forge a commit to the repository as well.

[0]: https://www.gnu.org/prep/maintain/maintain.html#Distribution-on-ftp_002egnu_002eorg

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> From: Mike Gerwitz <mtg@gnu.org>
> Cc: emacs-devel@gnu.org, Andreas Schwab <schwab@suse.de>,  nicolas@petton.fr,  rostislav.svoboda@gmail.com
> Date: Wed, 13 Sep 2017 11:12:49 -0400
> 
> Also, the tarball was uploaded to ftp.gnu.org, and signed.  Uploading to
> ftp.gnu.org itself requires the request to be signed with a GPG key
> registered on Savannah.[0]  This level of security is greater and more
> formal than repository commits/tags.

Indeed.

> If someone's system were compromised to the point of being able to
> successfully upload to ftp.gnu.org, chances are that they'll be able to
> forge a commit to the repository as well.

Before the announcement went out, the tarball was downloaded from
ftp.gnu.org to 3 different machines by 2 different people, built on
all 3 machines independently, and the build verified to not have the
vulnerability which Emacs 25.3 was supposed to fix.  I think this made
the possibility of tampering negligibly small, if not strictly zero.

Re: [ANNOUNCE] Emacs 25.3 released

[Nicolas Petton]

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

Eli Zaretskii <eliz@gnu.org> writes:

> There should be no security vulnerabilities, either.  Ever.  But there
> was, this time.  So we wanted to put the tarball out the door quickly
> and safely, because that's what the community expected.
>
> We should all thank Nicolas who did a splendid job, just a few hours
> after I gave him the final patch.  There's no need to pounce on him or
> make the (false) presentation of his job as less than perfect.

Thank you Eli (and the others as well) for your kind words.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ANNOUNCE] Emacs 25.3 released

[John Wiegley]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

EZ> We should all thank Nicolas who did a splendid job, just a few hours after
EZ> I gave him the final patch. There's no need to pounce on him or make the
EZ> (false) presentation of his job as less than perfect.

Indeed, thanks so much to everyone who got this out quickly enough that coming
back from vacation today I find everything was resolved in the meantime. :)

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

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> From: Rostislav Svoboda <rostislav.svoboda@gmail.com>
> Date: Tue, 12 Sep 2017 14:10:00 +0200
> Cc: Nicolas Petton <nicolas@petton.fr>, Emacs Devel <emacs-devel@gnu.org>
> 
> Except the last commit containing [dramatic pause] we don't know what!?!

You do know, as it was posted:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28350#54
  http://lists.gnu.org/archive/html/bug-gnu-emacs/2017-09/msg00353.html

Re: [ANNOUNCE] Emacs 25.3 released

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

  > That would mean the Emacs 25.3 is almost open source.

We do not aim to make our software "open source".
That term stands for a political philosophy that we don't follow.
GNU Emacs is meant to be free (libre, svobodniy) software.

See https://gnu.org/philosophy/open-source-misses-the-point.html
for more explanation of the difference between free software and open
source.  See also https://thebaffler.com/past/the_meme_hustler for
Evgeny Morozov's article on the same point.

Emacs 25.3 needs to be released as free software, and that requires
releasing the source code under a proper license.  Isn't that so
already?  Emacs releases are always source code, not binary.

-- 
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: [ANNOUNCE] Emacs 25.3 released

[Jorge A. Alfaro-Murillo]

Richard Stallman writes:

> See also https://thebaffler.com/past/the_meme_hustler for
> Evgeny Morozov's article on the same point.

It seems like that link doesn't work anymore. This one works, though:

https://thebaffler.com/salvos/the-meme-hustler

Best,
-- 
Jorge.

Re: [ANNOUNCE] Emacs 25.3 released

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

Thanks.

-- 
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: [ANNOUNCE] Emacs 25.3 released

[Stefan Monnier]

> That would mean the Emacs 25.3 is almost open source.

Of course Emacs doesn't care to be open source or not.
It makes every effort to be as Free Software as can be, tho, and 25.3 is
no exception.


        Stefan

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

On September 12, 2017 2:56:24 PM GMT+03:00, Andreas Schwab <schwab@suse.de> wrote:
> On Sep 12 2017, Nicolas Petton <nicolas@petton.fr> wrote:
> 
> > Andreas Schwab <schwab@suse.de> writes:
> >
> >> The release has not been tagged.
> >
> > No, as there's no corresponding git commit yet.
> 
> Why not?  A release should never be make out of the blue.
> 
> Andreas.

Because I asked Nicolas to produce the tarball first and leave the rest
for later.  This was no normal release.

Re: [ANNOUNCE] Emacs 25.3 released

[Philippe Vaucher]

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

>
> This vulnerability was introduced in Emacs 19.29.  To work around that
> in Emacs versions before 25.3, append the following to your ~/.emacs
> init file:
>

Does a vulnerability that has been there since that long really deserve
such a rushed release?

I mean, you could have gone through the classic release procedure with
tags/branches etc and maybe delay the release for 2-3 days. Would it really
have changed something in that case?

I don't understand why this particular security issue was treated that
dramatically, but maybe I'm missing something.

Philippe

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

Re: [ANNOUNCE] Emacs 25.3 released

[Paul Eggert]

On 09/12/2017 09:05 AM, Philippe Vaucher wrote:
> Does a vulnerability that has been there since that long really 
> deserve such a rushed release?
>
> I mean, you could have gone through the classic release procedure with 
> tags/branches etc and maybe delay the release for 2-3 days. Would it 
> really have changed something in that case?
>
> I don't understand why this particular security issue was treated that 
> dramatically, but maybe I'm missing something.

The security issue was quite bad. Adding tags and branches is a matter 
of minutes, not days. It hasn't been done yet (which is not a good 
thing), but it should get done reasonably soon.

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 12 Sep 2017 09:30:44 -0700
> 
> Adding tags and branches is a matter of minutes, not days. It hasn't
> been done yet (which is not a good thing), but it should get done
> reasonably soon.

AFAIU, Nicolas is working on this as we speak.

Getting the Git repository in order is much less urgent than putting
the tarball out the door, so I asked Nicolas to do that in this order.
I don't see why this small lag is so important.  Given the nature of
the problem, the priorities were clear, I don't think they can be
controversial.

Re: [ANNOUNCE] Emacs 25.3 released

[Thien-Thi Nguyen]

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


() Eli Zaretskii <eliz@gnu.org>
() Tue, 12 Sep 2017 19:52:26 +0300

   Getting the Git repository in order is much less urgent than
   putting the tarball out the door, so I asked Nicolas to do
   that in this order.  I don't see why this small lag is so
   important.  Given the nature of the problem, the priorities
   were clear, I don't think they can be controversial.

I think the lag is important because it represents "attack
surface" (for FUD) to defend.  Look at all the noise already
precipitated.  A few seconds doing "git {commit, tag, push}"
benefits everyone interested in skipping this noise, greatly.

If those operations are not sufficient to get the repo in order,
then i suggest they be done prior to tarball publication,
anyway, but on a provisional branch.  Afterwards, the proper
"getting the repo in order" operations can work w/ that branch
to merge it back to ‘master’ or whatever.

In sum: IMHO it's fine to deviate from full release protocol if
the deviation maintains transparency.  When transparency is
lost, we need (annoying :-D) ml threads to find it again.

-- 
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (query)
   (pcase (context query)
     (`(technical ,ml) (correctp ml))
     ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> From: Thien-Thi Nguyen <ttn@gnu.org>
> Date: Tue, 12 Sep 2017 20:26:10 +0200
> 
> I think the lag is important because it represents "attack
> surface" (for FUD) to defend.  Look at all the noise already
> precipitated.

Experience shows that noise is unavoidable, no matter what we do or
don't do.  Thus, the fact that there is noise proves or disproves
nothing.

> If those operations are not sufficient to get the repo in order,
> then i suggest they be done prior to tarball publication,
> anyway, but on a provisional branch.  Afterwards, the proper
> "getting the repo in order" operations can work w/ that branch
> to merge it back to ‘master’ or whatever.

Experience taught me that Git is tricky enough to cause even
experience users of Git to make mistakes from time to time.  And in
this case even a slight risk of making a mistake was entirely
unacceptable.  So we've chosen a safer way, with Git issues out of the
critical path.  From my POV, the result was smashing success.

> In sum: IMHO it's fine to deviate from full release protocol if
> the deviation maintains transparency.  When transparency is
> lost, we need (annoying :-D) ml threads to find it again.

The transparency was not lost, because the patch was posted here in
advance.

Re: [ANNOUNCE] Emacs 25.3 released

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

  > > I think the lag is important because it represents "attack
  > > surface" (for FUD) to defend.  Look at all the noise already
  > > precipitated.

  > Experience shows that noise is unavoidable, no matter what we do or
  > don't do.  Thus, the fact that there is noise proves or disproves
  > nothing.

That is my experience too.  We shouldn't worry ourselves about
opportunities for FUD, because they are always plentiful.

-- 
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: [ANNOUNCE] Emacs 25.3 released

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

  > I think the lag is important because it represents "attack
  > surface" (for FUD) to defend.

Let's not overstate the importance of a few confused messages.

-- 
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: [ANNOUNCE] Emacs 25.3 released

[Thien-Thi Nguyen]

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


() Richard Stallman <rms@gnu.org>
() Wed, 13 Sep 2017 12:39:49 -0400

     > I think the lag is important because it represents
     > "attack surface" (for FUD) to defend.

   Let's not overstate the importance of a few confused
   messages.

The confusion for people who understand is zero.  For those who
do not understand, it is variable and likewise its import (i.e.,
the import cannot be overstated for those people).

The primary reason to maximize process transparency is to reduce
potential misunderstanding.  Sorry, i was not clear about that
(instead i focused on the secondary point -- the effort involved
to handle one particular source of potential misunderstanding).

Anyway, i'm glad to see the lag was small.  Cool.

-- 
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (query)
   (pcase (context query)
     (`(technical ,ml) (correctp ml))
     ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> From: Thien-Thi Nguyen <ttn@gnu.org>
> Date: Thu, 14 Sep 2017 08:51:40 +0200
> 
> The primary reason to maximize process transparency is to reduce
> potential misunderstanding.

That's the advantage, yes.  The (not insignificant) disadvantage is
that every revealed detail of the process tends to trigger a
non-trivial amount of discussions, objections, counter-proposals, etc.
When there's no urgency, this disadvantage is negligible, and should
be generally disregarded.  But when the action should be urgent, the
optimal balance between transparency and just getting the job done
shifts.  I think in this case the balance was about right.

Ultimately, in such extremal situations, the community should trust
those who do the job.  If they are not trusted, they shouldn't be
asked to do the job in the first place.

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> From: Philippe Vaucher <philippe.vaucher@gmail.com>
> Date: Tue, 12 Sep 2017 18:05:29 +0200
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
>  This vulnerability was introduced in Emacs 19.29. To work around that
>  in Emacs versions before 25.3, append the following to your ~/.emacs
>  init file:
> 
> Does a vulnerability that has been there since that long really deserve such a rushed release?

The same question, more or less, was already asked and answered, in
the positive.  People actually wanted the release even earlier, but we
had to wait for a day until Nicolas could find free time.

> I don't understand why this particular security issue was treated that dramatically, but maybe I'm missing
> something.

That's what everyone wanted.  Just read the lists.

Re: [ANNOUNCE] Emacs 25.3 released

[Philippe Vaucher]

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

>
> > Does a vulnerability that has been there since that long really deserve
> such a rushed release?
>
> The same question, more or less, was already asked and answered, in
> the positive.  People actually wanted the release even earlier, but we
> had to wait for a day until Nicolas could find free time.
>
> > I don't understand why this particular security issue was treated that
> dramatically, but maybe I'm missing
> > something.
>
> That's what everyone wanted.  Just read the lists.
>

Sorry that I missed it. I'll read the other threads then, thanks.

Philippe

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

Re: [ANNOUNCE] Emacs 25.3 released

[Timur Aydin]

On 9/12/2017 7:05 PM, Philippe Vaucher wrote:
> Does a vulnerability that has been there since that long really deserve 
> such a rushed release?

Yes it has been there for a very long time, without having been 
discovered. But now that it is discovered, and people have started to 
talk about it, it represents a substantial attack surface. As a result, 
it became *very* urgent to provide a fix for it.

-- 
Timur

Re: [ANNOUNCE] Emacs 25.3 released

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

  > Does a vulnerability that has been there since that long really deserve
  > such a rushed release?

Any vulnerability that doesn't involve a mistake by the user
calls for a quick fix.

How long the bug has existed does not change anything.

  > I mean, you could have gone through the classic release procedure with
  > tags/branches etc and maybe delay the release for 2-3 days. Would it really
  > have changed something in that case?

That is not an real reason for delay.

There is nothing sacred about the usual release procedure.
We use it under normal circumstances
because under normal circumstances it's useful:
it helps us avoid errors.

It helps us avoid errors because a normal release includes
lots of changes.

This situation is not like that, so there was no need
for that procedure.

-- 
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: [ANNOUNCE] Emacs 25.3 released

[Roland Winkler]

On Mon, Sep 11 2017, Nicolas Petton wrote:
> This vulnerability was introduced in Emacs 19.29.  To work around that
> in Emacs versions before 25.3, append the following to your ~/.emacs
> init file:
>
>   (eval-after-load "enriched"
>     '(defun enriched-decode-display-prop (start end &optional param)
>        (list start end)))

Many users may have the problem that they cannot upgrade immediately to
25.3.  Is it fair to say that putting the above lines of code in
~/.emacs fully protects the user from the vulnerability?  If yes, we may
want to advertise these lines of code more broadly.  Or do the above
lines of code provide only an incomplete fix?  Then, what can users do
instead when they still have to use older versions of emacs?

Re: [ANNOUNCE] Emacs 25.3 released

[Paul Eggert]

On 09/12/2017 09:06 AM, Roland Winkler wrote:
> Is it fair to say that putting the above lines of code in
> ~/.emacs fully protects the user from the vulnerability?

Yes, if they avoid options like -Q that bypass ~/.emacs.

> If yes, we may
> want to advertise these lines of code more broadly.

What do you suggest? We sent email to info-gnu. It's been publicized on 
Reddit, OpenNET (in Russian), Linux-Magazin (in German), and so forth.

Re: [ANNOUNCE] Emacs 25.3 released

[Roland Winkler]

On Tue Sep 12 2017 Paul Eggert wrote:
> On 09/12/2017 09:06 AM, Roland Winkler wrote:
> > Is it fair to say that putting the above lines of code in
> > ~/.emacs fully protects the user from the vulnerability?
> 
> Yes, if they avoid options like -Q that bypass ~/.emacs.
> 
> > If yes, we may
> > want to advertise these lines of code more broadly.
> 
> What do you suggest? We sent email to info-gnu. It's been publicized on 
> Reddit, OpenNET (in Russian), Linux-Magazin (in German), and so forth.

I see, thanks.  I only knew about Nico's post here on emacs-devel.
I do not check the sources you mentioned.

I expect that (soon) http://www.gnu.org/software/emacs/ gets
updated, too.  So far, it only advertises emacs 25.2.

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> Date: Tue, 12 Sep 2017 11:54:39 -0500
> From: "Roland Winkler" <winkler@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> I expect that (soon) http://www.gnu.org/software/emacs/ gets
> updated, too.  So far, it only advertises emacs 25.2.

Yes, Nicolas is working on that, too:

  http://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00221.html

Re: [ANNOUNCE] Emacs 25.3 released

[Paul Eggert]

On 09/12/2017 10:12 AM, Eli Zaretskii wrote:
>> I expect that (soon)http://www.gnu.org/software/emacs/  gets
>> updated, too.  So far, it only advertises emacs 25.2.
> Yes, Nicolas is working on that, too:

Arghh, I didn't know that. I updated the two web pages talking about 
release numbers (emacs.html and history.html) just before reading this 
email. I'll CC: this to Nicolas.

By the way, what's the procedure for updating the online manual? I could 
not find it written down anywhere. Not a big deal now since the 25.2 
manual is fine, but it would be helpful to know how to do it in the future.

Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org, Nicolas Petton <nicolas@petton.fr>
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 12 Sep 2017 10:40:10 -0700
> 
> On 09/12/2017 10:12 AM, Eli Zaretskii wrote:
> >> I expect that (soon)http://www.gnu.org/software/emacs/  gets
> >> updated, too.  So far, it only advertises emacs 25.2.
> > Yes, Nicolas is working on that, too:
> 
> Arghh, I didn't know that.

He said that just today.

> I updated the two web pages talking about release numbers
> (emacs.html and history.html) just before reading this email. I'll
> CC: this to Nicolas.

I'd appreciate if you'd talked to me first in such cases.  It should
be clear that I have some handle on the situation.  These chaotic,
uncoordinated efforts by several people independently doing what they
think is best are not how we should handle such situations.

Re: [ANNOUNCE] Emacs 25.3 released

[Nicolas Petton]

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

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

> Arghh, I didn't know that.

That's fine, thanks for updating it.

> I updated the two web pages talking about 
> release numbers (emacs.html and history.html) just before reading this 
> email. I'll CC: this to Nicolas.
>
> By the way, what's the procedure for updating the online manual? I could 
> not find it written down anywhere. Not a big deal now since the 25.2 
> manual is fine, but it would be helpful to know how to do it in the
> future.

It's documented at the end of make-tarball.txt.

Cheers,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ANNOUNCE] Emacs 25.3 released

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

Perhaps we should rename the Emacs 25.2 tarball and all the other old
tarballs, adding a suffix saying do not use.

-- 
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: [ANNOUNCE] Emacs 25.3 released

[Ulrich Mueller]

>>>>> On Wed, 13 Sep 2017, Richard Stallman wrote:

> Perhaps we should rename the Emacs 25.2 tarball and all the other
> old tarballs, adding a suffix saying do not use.

Please don't. That would break the download for distros who rely on
pristine upstream sources and apply separate patches. For example,
Gentoo still has packages app-editors/emacs-23.4-r16 and
app-editors/emacs-24.5-r4 (of course, both *with* the fix for
enriched-mode).

Ulrich

Re: [ANNOUNCE] Emacs 25.3 released

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

  > Please don't. That would break the download for distros who rely on
  > pristine upstream sources and apply separate patches. For example,
  > Gentoo still has packages app-editors/emacs-23.4-r16 and
  > app-editors/emacs-24.5-r4 (of course, both *with* the fix for
  > enriched-mode).

So how do we inform people not to download the broken versions?

If Gentoo will have a patch to fix that version,
can't the same patch put in the new file name of that version?

-- 
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: [ANNOUNCE] Emacs 25.3 released

[Ulrich Mueller]

>>>>> On Wed, 13 Sep 2017, Richard Stallman wrote:

>> Please don't. That would break the download for distros who rely on
>> pristine upstream sources and apply separate patches. For example,
>> Gentoo still has packages app-editors/emacs-23.4-r16 and
>> app-editors/emacs-24.5-r4 (of course, both *with* the fix for
>> enriched-mode).

> So how do we inform people not to download the broken versions?

Bugs (security or other) happen all the time, so most old versions
will be broken in some way. In spite of that, I am not aware of any
project that is renaming its old tarballs.

It is also not the first time there is a security bug in GNU Emacs
(although it's been a while since the last one). A quick search shows
CVE-2014-3421, -3422, -3423, and -3424 concerning insecure handling
of temporary files in gnus-fun.el, find-gc.el, browse-url.el, and
tramp.el. No renaming of tarballs took place, neither for that issue
(which affected Emacs 24.3) nor for any previous ones.

I would also assume that users will generally download only the latest
version of any given software, and that they are aware that old
versions can contain bugs.

> If Gentoo will have a patch to fix that version,
> can't the same patch put in the new file name of that version?

Sure, we could update the filename in our ebuild. Which would mean
more work though. We have some 19000 packages in the distro, and
there's other work to do than monitoring if upstream tarballs have
been renamed.

Ulrich

Re: Emacs 25.3 released

[Etienne Prud’homme]

Ulrich Mueller <ulm@gentoo.org> writes:

>>>>>> On Wed, 13 Sep 2017, Richard Stallman wrote:
>
>>> Please don't. That would break the download for distros who rely on
>>> pristine upstream sources and apply separate patches. For example,
>>> Gentoo still has packages app-editors/emacs-23.4-r16 and
>>> app-editors/emacs-24.5-r4 (of course, both *with* the fix for
>>> enriched-mode).
>
>> So how do we inform people not to download the broken versions?
>
> Bugs (security or other) happen all the time, so most old versions
> will be broken in some way. In spite of that, I am not aware of any
> project that is renaming its old tarballs.
>
> It is also not the first time there is a security bug in GNU Emacs
> (although it's been a while since the last one). A quick search shows
> CVE-2014-3421, -3422, -3423, and -3424 concerning insecure handling
> of temporary files in gnus-fun.el, find-gc.el, browse-url.el, and
> tramp.el. No renaming of tarballs took place, neither for that issue
> (which affected Emacs 24.3) nor for any previous ones.
>
> I would also assume that users will generally download only the latest
> version of any given software, and that they are aware that old
> versions can contain bugs.
>
>> If Gentoo will have a patch to fix that version,
>> can't the same patch put in the new file name of that version?
>
> Sure, we could update the filename in our ebuild. Which would mean
> more work though. We have some 19000 packages in the distro, and
> there's other work to do than monitoring if upstream tarballs have
> been renamed.
>
> Ulrich

Was there any fix for older version than 24?

Maybe we could patch older versions too.  I think it might be helpful to
setup a critical update mechanism.  By that I mean patching every
versions affected automatically with the semantic version system
(increment by 0.0.1 for bug fixes).  By the way, are tarballs
automatically generated?  If not, would it be hard to implement?

ps: I’m grateful for petton’s work and not trying to minimize what he
did.

--
Etienne

Re: Emacs 25.3 released

[Nicolas Petton]

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

Etienne Prud’homme <e.e.f.prudhomme@gmail.com> writes:

> By the way, are tarballs
> automatically generated?  If not, would it be hard to implement?

They are not automatically built.  Unfortunately, there is manual work
(usually fixes in the ChangeLog files, updating etc/AUTHORS which often
involves updating admin/authors.el) to be done for each tarball.

Cheers,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [ANNOUNCE] Emacs 25.3 released

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

You've convinced me guess it is ok not to rename the old tar files.
Thanks.

-- 
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: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii]

> From: Roland Winkler <winkler@gnu.org>
> Date: Tue, 12 Sep 2017 11:06:14 -0500
> 
> >   (eval-after-load "enriched"
> >     '(defun enriched-decode-display-prop (start end &optional param)
> >        (list start end)))
> 
> Many users may have the problem that they cannot upgrade immediately to
> 25.3.  Is it fair to say that putting the above lines of code in
> ~/.emacs fully protects the user from the vulnerability?

Yes, it does.

> If yes, we may want to advertise these lines of code more broadly.

Please feel free to do that.

> Or do the above lines of code provide only an incomplete fix?

It's a complete fix, in the sense that it completely removes the
vulnerability, by disabling processing of 'display' properties in
Enriched text.

Re: [ANNOUNCE] Emacs 25.3 released

[Phillip Lord]

On Tue, September 12, 2017 4:06 pm, Roland Winkler wrote:
> On Mon, Sep 11 2017, Nicolas Petton wrote:
>
>> This vulnerability was introduced in Emacs 19.29.  To work around that
>> in Emacs versions before 25.3, append the following to your ~/.emacs init
>> file:
>>
>>
>> (eval-after-load "enriched"
>> '(defun enriched-decode-display-prop (start end &optional param)
>> (list start end)))
>>
>
> Many users may have the problem that they cannot upgrade immediately to
> 25.3.  Is it fair to say that putting the above lines of code in
> ~/.emacs fully protects the user from the vulnerability?  If yes, we may
> want to advertise these lines of code more broadly.  Or do the above lines
> of code provide only an incomplete fix?  Then, what can users do instead
> when they still have to use older versions of emacs?



What do we not put a "vulnerability" package onto ELPA, then install this
by default. This way, new emacs releases would provide an automatic
mechanism for fixing vulnerabilities. And, for old emacs, the advice would
be "M-x package-install vulnerability".

Re: [ANNOUNCE] Emacs 25.3 released

[Stefan Monnier]

> What do we not put a "vulnerability" package onto ELPA, then install this
> by default. This way, new emacs releases would provide an automatic
> mechanism for fixing vulnerabilities. And, for old Emacs, the advice would
> be "M-x package-install vulnerability".

I wouldn't call it "vulnerability" since it sounds like you're willingly
installing a backdoor.  But having a "security-patches" package might
make sense.


        Stefan

security-patches package (was: [ANNOUNCE] Emacs 25.3 released)

[Ted Zlatanov]

On Tue, 12 Sep 2017 21:46:38 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> having a "security-patches" package might make sense.

I would love to see that as well, especially if it was well tested in a
CI system against various versions of Emacs.

What needs to happen so the experience is seamless?

Ted

Re: security-patches package

[Stefan Monnier]

SM> having a "security-patches" package might make sense.
> I would love to see that as well, especially if it was well tested in a
> CI system against various versions of Emacs.
> What needs to happen so the experience is seamless?

Step one is to create this package in elpa.git, putting the fix for the
enriched.el bug.


        Stefan

Re: security-patches package

[Ted Zlatanov]

On Fri, 15 Sep 2017 08:32:16 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> having a "security-patches" package might make sense.
>> I would love to see that as well, especially if it was well tested in a
>> CI system against various versions of Emacs.
>> What needs to happen so the experience is seamless?

SM> Step one is to create this package in elpa.git, putting the fix for the
SM> enriched.el bug.

A package is pretty easy but I have a few questions before putting that
out:

* how do we prevent accidental or malicious commits to this package?
  Could it maybe live in a special "GNU ELPA security updates" archive
  separate from elpa.git?

* should it be signed+released in a special way? How do we test it?

* what version of Emacs will begin to check for this package?

* Can we do push notifications somehow or are we limited to polling?

* should there be a special mailing list for internal discussions?

* how do we make the experience seamless (on startup, during a
  long-running session, unattended, for a whole site)?

In a related vein, I mentioned a while ago that it would be really nice
to see the changes (from what's installed) to all the code in a package
before upgrading it. I think for security updates that would be
especially useful.

Thanks
Ted

Re: security-patches package

[Phillip Lord]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Fri, 15 Sep 2017 08:32:16 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 
>
> SM> having a "security-patches" package might make sense.
>>> I would love to see that as well, especially if it was well tested in a
>>> CI system against various versions of Emacs.
>>> What needs to happen so the experience is seamless?
>
> SM> Step one is to create this package in elpa.git, putting the fix for the
> SM> enriched.el bug.
>
> A package is pretty easy but I have a few questions before putting that
> out:
>
> * how do we prevent accidental or malicious commits to this package?
>   Could it maybe live in a special "GNU ELPA security updates" archive
>   separate from elpa.git?

I think this is not important. It wouldn't have any special privilege;
i.e. the malicious user could do the same nasty things in any package.
Accidental commits could just be controlled by constraining the
*release* -- that is commits would be normal, but they wouldn't go live.


> * should it be signed+released in a special way? How do we test it?

Testing is hard, unless we produce a "alpha" version of ELPA (try saying
that when drunk).

> * what version of Emacs will begin to check for this package?

Emacs 26, more or less by definition.

> * Can we do push notifications somehow or are we limited to polling?

Polling. Worse polling at the users request, because ELPA doesn't also
update.

Changing ELPA to auto-update the archive would be a good thing to do, I
think.

> * should there be a special mailing list for internal discussions?
>
> * how do we make the experience seamless (on startup, during a
>   long-running session, unattended, for a whole site)?
>
> In a related vein, I mentioned a while ago that it would be really nice
> to see the changes (from what's installed) to all the code in a package
> before upgrading it. I think for security updates that would be
> especially useful.

That would be cute, for non-security also. Give people a reason to
update.

Phil

Re: security-patches package

[Stefan Monnier]

> Changing ELPA to auto-update the archive would be a good thing to do, I
> think.

I'm firmly opposed to making any program initiate network connections
without explicit user request.


        Stefan

Re: security-patches package

[Phillip Lord]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Changing ELPA to auto-update the archive would be a good thing to do, I
>> think.
>
> I'm firmly opposed to making any program initiate network connections
> without explicit user request.

The middle-ground is to ask people first time, then
auto-update/not-update into the future.

Phil

Re: security-patches package

[Ted Zlatanov]

On Thu, 21 Sep 2017 21:01:56 +0100 phillip.lord@russet.org.uk (Phillip Lord) wrote: 

PL> Ted Zlatanov <tzz@lifelogs.com> writes:
>> * how do we prevent accidental or malicious commits to this package?
>> Could it maybe live in a special "GNU ELPA security updates" archive
>> separate from elpa.git?

PL> I think this is not important. It wouldn't have any special privilege;
PL> i.e. the malicious user could do the same nasty things in any package.
PL> Accidental commits could just be controlled by constraining the
PL> *release* -- that is commits would be normal, but they wouldn't go live.

The proposition is to check these packages more frequently and for the
user to trust them more than any other packages, so I think there is
some value to that. But I'm OK with just using the GNU ELPA as long as
the packages are tagged in a special way.

>> * Can we do push notifications somehow or are we limited to polling?

PL> Polling. Worse polling at the users request, because ELPA doesn't also
PL> update.

PL> Changing ELPA to auto-update the archive would be a good thing to do, I
PL> think.

On Thu, 21 Sep 2017 23:12:47 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> I'm firmly opposed to making any program initiate network connections
SM> without explicit user request.

I understand the concern.

Let's say the user can turn auto checking on, but normally it will just
be a prominent menu item or button they can click to check for an update?

Ted

Re: security-patches package

[Stephen Leake]

Ted Zlatanov <tzz@lifelogs.com> writes:

>>> * Can we do push notifications somehow or are we limited to polling?
>
> PL> Polling. Worse polling at the users request, because ELPA doesn't also
> PL> update.
>
> PL> Changing ELPA to auto-update the archive would be a good thing to do, I
> PL> think.
>
> On Thu, 21 Sep 2017 23:12:47 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 
>
> SM> I'm firmly opposed to making any program initiate network connections
> SM> without explicit user request.
>
> I understand the concern.
>
> Let's say the user can turn auto checking on, but normally it will just
> be a prominent menu item or button they can click to check for an update?

+1

-- 
-- Stephe

Hotfixing older Emacsen? Was: [ANNOUNCE] Emacs 25.3 released

[Clément Pit-Claudel]

On 2017-09-11 22:52, Nicolas Petton wrote:
> This vulnerability was introduced in Emacs 19.29.  To work around that
> in Emacs versions before 25.3, append the following to your ~/.emacs
> init file: [...]

Crazy though: why don't we hot-patch existing Emacs installations?
Concretely, that would mean including that fix in a widely used ELPA or MELPA package. Then users would get the fix upon the next update.

In the long run, we could have an emacs-security-patches package on ELPA that's installed by default, and we could publish security fixes to that repo.
(We don't currently have this, so we could use another common package instead for this specific issue)

Wouldn't this make it much easier to fix vulnerabilities, without requiring a whole-Emacs update?

Clément.

Re: Hotfixing older Emacsen? Was: [ANNOUNCE] Emacs 25.3 released

[Phillip Lord]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 2017-09-11 22:52, Nicolas Petton wrote:
>> This vulnerability was introduced in Emacs 19.29.  To work around that
>> in Emacs versions before 25.3, append the following to your ~/.emacs
>> init file: [...]
>
> Crazy though: why don't we hot-patch existing Emacs installations?
> Concretely, that would mean including that fix in a widely used ELPA
> or MELPA package. Then users would get the fix upon the next update.
>
> In the long run, we could have an emacs-security-patches package on
> ELPA that's installed by default, and we could publish security fixes
> to that repo.
> (We don't currently have this, so we could use another common package
> instead for this specific issue)
>
> Wouldn't this make it much easier to fix vulnerabilities, without
> requiring a whole-Emacs update?


Putting fixes in another package doesn't make sense. Adding a
security-hotfix package to ELPA is simple and easy to do. For future
Emacs, it would be possible to do things like auto-install that package.

Phil

Re: Hotfixing older Emacsen? Was: [ANNOUNCE] Emacs 25.3 released

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

  > Crazy though: why don't we hot-patch existing Emacs installations?
  > Concretely, that would mean including that fix in a widely used ELPA or MELPA package. Then users would get the fix upon the next update.

This verges on a universal back door, aka "auto-upgrade"
which is a form of malware normally found in proprietary software.

We must not do that.  No matter what the disease, this "cure" is worse.

See https://gnu.org/malware/proprietary-back-doors.html .
-- 
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: Hotfixing older Emacsen? Was: [ANNOUNCE] Emacs 25.3 released

[Nicolas Petton]

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

Richard Stallman <rms@gnu.org> writes:

>   > Crazy though: why don't we hot-patch existing Emacs installations?
>   > Concretely, that would mean including that fix in a widely used ELPA or MELPA package. Then users would get the fix upon the next update.
>
> This verges on a universal back door, aka "auto-upgrade"
> which is a form of malware normally found in proprietary software.

What if the user was asked for a confirmation before upgrading?  Would
that be a good solution?

Cheers,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Hotfixing older Emacsen? Was: [ANNOUNCE] Emacs 25.3 released

[Stefan Monnier]

>> > Crazy though: why don't we hot-patch existing Emacs installations?
>> > Concretely, that would mean including that fix in a widely used ELPA
>> > or MELPA package. Then users would get the fix upon the next update.
>> This verges on a universal back door, aka "auto-upgrade"
>> which is a form of malware normally found in proprietary software.
> What if the user was asked for a confirmation before upgrading?
> Would that be a good solution?

I think fixes should be in a separate package.
If we really feel it's necessary, we could consider adding some code to
some unrelated popular package which could do something like:
- look for known bugs (fixed in security-patches)
- if found some, tell the user, suggesting to install the
  security-patches package


-- Stefan

Re: Hotfixing older Emacsen? Was: [ANNOUNCE] Emacs 25.3 released

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

  > I think fixes should be in a separate package.

Sorry, I don't follow you.

-- 
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: Hotfixing older Emacsen? Was: [ANNOUNCE] Emacs 25.3 released

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

  > What if the user was asked for a confirmation before upgrading?  Would
  > that be a good solution?

That still implies pressure on the user to upgrade.

Informing the user that there is a new version, without pressure,
would be ok.  We can say why we think it is highly desirable to
upgrade and suggest looking at other materials about the issue.  But
not pressure!


-- 
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: [ANNOUNCE] Emacs 25.3 released

[Charles A. Roelli]

> From: Nicolas Petton <nicolas@petton.fr>
> Date: Mon, 11 Sep 2017 22:52:00 +0200
> 
> Hi!
> 
> Version 25.3 of the Emacs text editor is now available.

Cheers, and thanks for getting this release out the door so
responsively.