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

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

[Troy Hinckley]

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

My company will not allow an install of Emacs 28 due to CVE-2022-45939. There is a patch for this in the master branch, but it did not make it in time for Emacs 28.2. We have many Emacs users who would like to upgrade to 28. What would be the effort to back port this fix and do an Emacs 28.3 release?


- Troy Hinckley

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

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

[Eli Zaretskii]

> Date: Mon, 13 Feb 2023 12:15:50 -0600
> From: Troy Hinckley <comms@dabrev.com>
> 
> My company will not allow an install of Emacs 28 due to CVE-2022-45939. There is a patch for this in the
> master branch, but it did not make it in time for Emacs 28.2. We have many Emacs users who would like to
> upgrade to 28. What would be the effort to back port this fix and do an Emacs 28.3 release?

Unfortunately, we don't have the resources to produce another v28.x
release.  Emacs 29.1 will start its pretest soon, and will have this
issue resolved when it is released, hopefully in a couple of months.

Alternatively, you could ask the distro which you are using (if you
are using a distro) to backport that patch to the Emacs 28 codebase.
Or patch the sources yourself and build Emacs, if that is how you
produce the binaries.

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

[lux]

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

On Mon, 2023-02-13 at 22:47 +0200, Eli Zaretskii wrote:
> > Date: Mon, 13 Feb 2023 12:15:50 -0600
> > From: Troy Hinckley <comms@dabrev.com>
> > 
> > My company will not allow an install of Emacs 28 due to CVE-2022-
> > 45939. There is a patch for this in the
> > master branch, but it did not make it in time for Emacs 28.2. We
> > have many Emacs users who would like to
> > upgrade to 28. What would be the effort to back port this fix and
> > do an Emacs 28.3 release?
> 
> Unfortunately, we don't have the resources to produce another v28.x
> release.  Emacs 29.1 will start its pretest soon, and will have this
> issue resolved when it is released, hopefully in a couple of months.
> 
> Alternatively, you could ask the distro which you are using (if you
> are using a distro) to backport that patch to the Emacs 28 codebase.
> Or patch the sources yourself and build Emacs, if that is how you
> produce the binaries.
> 

Hi, I can fix the CVE-2022-45939, this is a patch.

Eli, can you merge into emacs-28 branch?


[-- Attachment #2: 0001-lib-src-etags.c-Fix-CVE-2022-45939.patch --]
[-- Type: text/x-patch, Size: 7952 bytes --]

From 637d57282ab332abbbfed27000cdf6dbf9ecd20e Mon Sep 17 00:00:00 2001
From: Xi Lu <lx@shellcodes.org>
Date: Tue, 14 Feb 2023 12:58:04 +0800
Subject: [PATCH] ; * lib-src/etags.c: Fix CVE-2022-45939.

---
 lib-src/etags.c | 149 ++++++++++++++++++++++++++++++++++++------------
 1 file changed, 113 insertions(+), 36 deletions(-)

diff --git a/lib-src/etags.c b/lib-src/etags.c
index f665f35fa60..c9c32691016 100644
--- a/lib-src/etags.c
+++ b/lib-src/etags.c
@@ -382,7 +382,7 @@ #define xrnew(op, n, m) ((op) = xnrealloc (op, n, (m) * sizeof *(op)))
 
 static language *get_language_from_langname (const char *);
 static void readline (linebuffer *, FILE *);
-static ptrdiff_t readline_internal (linebuffer *, FILE *, char const *);
+static ptrdiff_t readline_internal (linebuffer *, FILE *, char const *, const bool);
 static bool nocase_tail (const char *);
 static void get_tag (char *, char **);
 static void get_lispy_tag (char *);
@@ -406,7 +406,9 @@ #define xrnew(op, n, m) ((op) = xnrealloc (op, n, (m) * sizeof *(op)))
 static void pfnote (char *, bool, char *, ptrdiff_t, intmax_t, intmax_t);
 static void invalidate_nodes (fdesc *, node **);
 static void put_entries (node *);
+static void clean_matched_file_tag (char const * const, char const * const);
 
+static void do_move_file (const char *, const char *);
 static char *concat (const char *, const char *, const char *);
 static char *skip_spaces (char *);
 static char *skip_non_spaces (char *);
@@ -1339,7 +1341,7 @@ main (int argc, char **argv)
 		  if (parsing_stdin)
 		    fatal ("cannot parse standard input "
 			   "AND read file names from it");
-		  while (readline_internal (&filename_lb, stdin, "-") > 0)
+		  while (readline_internal (&filename_lb, stdin, "-", false) > 0)
 		    process_file_name (filename_lb.buffer, lang);
 		}
 	      else
@@ -1387,9 +1389,6 @@ main (int argc, char **argv)
   /* From here on, we are in (CTAGS && !cxref_style) */
   if (update)
     {
-      char *cmd =
-	xmalloc (strlen (tagfile) + whatlen_max +
-		 sizeof "mv..OTAGS;grep -Fv '\t\t' OTAGS >;rm OTAGS");
       for (i = 0; i < current_arg; ++i)
 	{
 	  switch (argbuffer[i].arg_type)
@@ -1400,17 +1399,8 @@ main (int argc, char **argv)
 	    default:
 	      continue;		/* the for loop */
 	    }
-	  char *z = stpcpy (cmd, "mv ");
-	  z = stpcpy (z, tagfile);
-	  z = stpcpy (z, " OTAGS;grep -Fv '\t");
-	  z = stpcpy (z, argbuffer[i].what);
-	  z = stpcpy (z, "\t' OTAGS >");
-	  z = stpcpy (z, tagfile);
-	  strcpy (z, ";rm OTAGS");
-	  if (system (cmd) != EXIT_SUCCESS)
-	    fatal ("failed to execute shell command");
+          clean_matched_file_tag (tagfile, argbuffer[i].what);
 	}
-      free (cmd);
       append_to_tagfile = true;
     }
 
@@ -1439,6 +1429,51 @@ main (int argc, char **argv)
   return EXIT_SUCCESS;
 }
 
+/*
+ * Equivalent to: mv tags OTAGS;grep -Fv ' filename ' OTAGS >tags;rm OTAGS
+ */
+static void
+clean_matched_file_tag (const char* tagfile, const char* match_file_name)
+{
+  FILE *otags_f = fopen ("OTAGS", "wb");
+  FILE *tag_f = fopen (tagfile, "rb");
+
+  if (otags_f == NULL)
+    pfatal ("OTAGS");
+
+  if (tag_f == NULL)
+    pfatal (tagfile);
+
+  int buf_len = strlen (match_file_name) + sizeof ("\t\t ") + 1;
+  char *buf = xmalloc (buf_len);
+  snprintf (buf, buf_len, "\t%s\t", match_file_name);
+
+  linebuffer line;
+  linebuffer_init (&line);
+  while (readline_internal (&line, tag_f, tagfile, true) > 0)
+    {
+      if (ferror (tag_f))
+        pfatal (tagfile);
+
+      if (strstr (line.buffer, buf) == NULL)
+        {
+          fprintf (otags_f, "%s\n", line.buffer);
+          if (ferror (tag_f))
+            pfatal (tagfile);
+        }
+    }
+  free (buf);
+  free (line.buffer);
+
+  if (fclose (otags_f) == EOF)
+    pfatal ("OTAGS");
+
+  if (fclose (tag_f) == EOF)
+    pfatal (tagfile);
+
+  do_move_file ("OTAGS", tagfile);
+  return;
+}
 
 /*
  * Return a compressor given the file name.  If EXTPTR is non-zero,
@@ -1822,7 +1857,7 @@ find_entries (FILE *inf)
 
   /* Else look for sharp-bang as the first two characters. */
   if (parser == NULL
-      && readline_internal (&lb, inf, infilename) > 0
+      && readline_internal (&lb, inf, infilename, false) > 0
       && lb.len >= 2
       && lb.buffer[0] == '#'
       && lb.buffer[1] == '!')
@@ -6861,7 +6896,7 @@ analyze_regex (char *regex_arg)
 	if (regexfp == NULL)
 	  pfatal (regexfile);
 	linebuffer_init (&regexbuf);
-	while (readline_internal (&regexbuf, regexfp, regexfile) > 0)
+	while (readline_internal (&regexbuf, regexfp, regexfile, false) > 0)
 	  analyze_regex (regexbuf.buffer);
 	free (regexbuf.buffer);
 	if (fclose (regexfp) != 0)
@@ -7209,11 +7244,13 @@ get_lispy_tag (register char *bp)
 
 /*
  * Read a line of text from `stream' into `lbp', excluding the
- * newline or CR-NL, if any.  Return the number of characters read from
- * `stream', which is the length of the line including the newline.
+ * newline or CR-NL (if `leave_cr` is false), if any.  Return the
+ * number of characters read from `stream', which is the length
+ * of the line including the newline.
  *
- * On DOS or Windows we do not count the CR character, if any before the
- * NL, in the returned length; this mirrors the behavior of Emacs on those
+ * On DOS or Windows, if `leave_cr` is false, we do not count the
+ * CR character, if any before the NL, in the returned length;
+ * this mirrors the behavior of Emacs on those
  * platforms (for text files, it translates CR-NL to NL as it reads in the
  * file).
  *
@@ -7221,7 +7258,7 @@ get_lispy_tag (register char *bp)
  * appended to `filebuf'.
  */
 static ptrdiff_t
-readline_internal (linebuffer *lbp, FILE *stream, char const *filename)
+readline_internal (linebuffer *lbp, FILE *stream, char const *filename, const bool leave_cr)
 {
   char *buffer = lbp->buffer;
   char *p = lbp->buffer;
@@ -7251,19 +7288,19 @@ readline_internal (linebuffer *lbp, FILE *stream, char const *filename)
 	  break;
 	}
       if (c == '\n')
-	{
-	  if (p > buffer && p[-1] == '\r')
-	    {
-	      p -= 1;
-	      chars_deleted = 2;
-	    }
-	  else
-	    {
-	      chars_deleted = 1;
-	    }
-	  *p = '\0';
-	  break;
-	}
+        {
+          if (!leave_cr && p > buffer && p[-1] == '\r')
+            {
+              p -= 1;
+              chars_deleted = 2;
+            }
+          else
+            {
+              chars_deleted = 1;
+            }
+          *p = '\0';
+          break;
+        }
       *p++ = c;
     }
   lbp->len = p - buffer;
@@ -7294,7 +7331,7 @@ readline_internal (linebuffer *lbp, FILE *stream, char const *filename)
 readline (linebuffer *lbp, FILE *stream)
 {
   linecharno = charno;		/* update global char number of line start */
-  ptrdiff_t result = readline_internal (lbp, stream, infilename);
+  ptrdiff_t result = readline_internal (lbp, stream, infilename, false);
   lineno += 1;			/* increment global line number */
   charno += result;		/* increment global char number */
 
@@ -7652,6 +7689,46 @@ etags_mktmp (void)
   return templt;
 }
 
+static void
+do_move_file(const char *src_file, const char *dst_file)
+{
+  if (rename (src_file, dst_file) == 0)
+    return;
+
+  FILE *src_f = fopen (src_file, "rb");
+  FILE *dst_f = fopen (dst_file, "wb");
+
+  if (src_f == NULL)
+    pfatal (src_file);
+
+  if (dst_f == NULL)
+    pfatal (dst_file);
+
+  int c;
+  while ((c = fgetc (src_f)) != EOF)
+    {
+      if (ferror (src_f))
+        pfatal (src_file);
+
+      if (ferror (dst_f))
+        pfatal (dst_file);
+
+      if (fputc (c, dst_f) == EOF)
+        pfatal ("cannot write");
+    }
+
+  if (fclose (src_f) == EOF)
+    pfatal (src_file);
+
+  if (fclose (dst_f) == EOF)
+    pfatal (dst_file);
+
+  if (unlink (src_file) == -1)
+    pfatal ("unlink error");
+
+  return;
+}
+
 /* Return a newly allocated string containing the file name of FILE
    relative to the absolute directory DIR (which should end with a slash). */
 static char *
-- 
2.39.1

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

[Eli Zaretskii]

> From: lux <lx@shellcodes.org>
> Cc: emacs-devel@gnu.org
> Date: Tue, 14 Feb 2023 13:07:44 +0800
> 
> Hi, I can fix the CVE-2022-45939, this is a patch.

We don't need a patch for that, we just need to cherry-pick the
related commits from emacs-29.

But that is not what the OP requested: he requested that we also
produce an Emacs 28.3 release.  And that is a much larger job, for
which we currently don't have the time or resources.

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

[Troy Hinckley]

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

If the commit was cherry picked to the emacs-28 branch, does that mean it’s just unreleased changes for Emacs 28? We are building from source, so that might be enough. I didn’t realize cutting a release was high effort.
On Feb 14, 2023 at 7:20 AM -0600, Eli Zaretskii <eliz@gnu.org>, wrote:
> > From: lux <lx@shellcodes.org>
> > Cc: emacs-devel@gnu.org
> > Date: Tue, 14 Feb 2023 13:07:44 +0800
> >
> > Hi, I can fix the CVE-2022-45939, this is a patch.
>
> We don't need a patch for that, we just need to cherry-pick the
> related commits from emacs-29.
>
> But that is not what the OP requested: he requested that we also
> produce an Emacs 28.3 release. And that is a much larger job, for
> which we currently don't have the time or resources.

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

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

[Eli Zaretskii]

> Date: Tue, 14 Feb 2023 10:09:43 -0600
> From: Troy Hinckley <comms@dabrev.com>
> Cc: emacs-devel@gnu.org
> 
> If the commit was cherry picked to the emacs-28 branch, does that mean it’s just unreleased changes for
> Emacs 28?

Yes.

> We are building from source, so that might be enough. I didn’t realize cutting a release was high
> effort. 

It's a non-trivial effort, yes.

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

[Lynn Winebarger]

On Tue, Feb 14, 2023 at 12:06 PM Troy Hinckley <comms@dabrev.com> wrote:
>
> If the commit was cherry picked to the emacs-28 branch, does that mean it’s just unreleased changes for Emacs 28? We are building from source, so that might be enough. I didn’t realize cutting a release was high effort.

FWIW, I suspect a lot of users get automated updates from their
packager of choice, whether it's linux distro, Cygwin, MSYS2, or
whatever.  If you look at their source packages, they routinely apply
these kinds of changes as updates to older releases.  Even if you
don't use that packager, you can still use their source package for
Emacs to get a version with the relevant security patches.

This is one of those cases where the practices of proprietary software
vendors and free software diverge.  Proprietary software vendors have
the sole legal right to update their software, so any updates have to
come from them.  WIth free software, many (maybe most) of us get
packages from a redistributor that takes on the responsibility of
providing high-priority fixes for existing installations without
requiring upstream maintainers to create a new release for every such
event, or push such releases out.  It may even be a bit more of a
burden to add an upstream release just for a single improvement.

Lynn

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

[lux]

On Thu, 2023-02-16 at 20:44 -0500, Lynn Winebarger wrote:
> On Tue, Feb 14, 2023 at 12:06 PM Troy Hinckley <comms@dabrev.com>
> wrote:
> > 
> > If the commit was cherry picked to the emacs-28 branch, does that
> > mean it’s just unreleased changes for Emacs 28? We are building
> > from source, so that might be enough. I didn’t realize cutting a
> > release was high effort.
> 
> FWIW, I suspect a lot of users get automated updates from their
> packager of choice, whether it's linux distro, Cygwin, MSYS2, or
> whatever.  If you look at their source packages, they routinely apply
> these kinds of changes as updates to older releases.  Even if you
> don't use that packager, you can still use their source package for
> Emacs to get a version with the relevant security patches.

Most Linux distributions rely on public CVE information for security
updates, I fixed 4 vulnerabilities[1], but to date, only one
vulnerability has been assigned a CVE number (CVE-2022-45939), so most
Linux distributions have not fixed the other three vulnerabilities.

Depending on the distro security updates are only available for Linux,
BSD etc, while Windows users cannot update automatically.


[1] patches:
-
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=d48bb4874bc6cd3e69c7a15fc3c91cc141025c51
-
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=01a4035c869b91c153af9a9132c87adb7669ea1c
-
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=9a3b08061feea14d6f37685ca1ab8801758bfd1c
-
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=1b4dc4691c1f87fc970fbe568b43869a15ad0d4c

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

[Tim Cross]

Eli Zaretskii <eliz@gnu.org> writes:

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

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

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

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

[Robert Pluim]

>>>>> On Wed, 15 Feb 2023 07:10:58 +1100, Tim Cross <theophilusx@gmail.com> said:

    Tim> Eli Zaretskii <eliz@gnu.org> writes:

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

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

The exploit is severe, in the sense that a car with faulty brakes is
dangerous: if you donʼt drive the car, there is no danger.
Uninstalling the emacs version of ctags/etags is enough to mitigate
this.

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

Yes, the FUD issue (and the associated hysteria from corporate IT
departments) is all too true (plus how many people run ctags or etags
as a privileged user?).

We *could* rush out a 28.3 release, I guess, given that thereʼs only
one actual non-doc change on the branch, but then again: how is that
any better than downstream just adding the CVE fix to their builds?

Robert
-- 

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

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


  > We *could* rush out a 28.3 release, I guess, given that thereʼs only
  > one actual non-doc change on the branch, but then again: how is that
  > any better than downstream just adding the CVE fix to their builds?

It is normal for users to download the tar file and build from that.
Most of them will not have any way to know that they should patch it.
If we make a 28.3 release with the fix, ordinary users will get that fix.
Otherwise, they won't know about it and won't install it.

Lynn Winebarger wrote:

  > FWIW, I suspect a lot of users get automated updates from their
  > packager of choice, whether it's [a GNU/Linux] distro, Cygwin, MSYS2, or
  > whatever.

Some users will get the fix that way, and that's good.  But we also
want users who build from our source release to get important fixes
like this one.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Eli Zaretskii]

> From: Tim Cross <theophilusx@gmail.com>
> Cc: lux <lx@shellcodes.org>, comms@dabrev.com, emacs-devel@gnu.org
> Date: Wed, 15 Feb 2023 07:10:58 +1100
> 
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But that is not what the OP requested: he requested that we also
> > produce an Emacs 28.3 release.  And that is a much larger job, for
> > which we currently don't have the time or resources.
> 
> While I understand the resourcing issues, I think this is the wrong
> decision. We are in the situation where the current released version of
> Emacs has a known security exploit with a severity classification of
> high (although this assessment seems to be under review) and the
> response seems to be "Sorry, we are too busy trying to get the next
> version released to deal with this". If we were actually close to an
> Emacs 29 release, then perhaps this would be reasonable, but we don't
> even have a release candidate out yet.
> 
> Failing to address a high security vulnerability for months is a
> disservice for the emacs user base and likely to be a blight on Emacs'
> reputation and only provides those against free software with free
> ammunition. In addition to the technical aspects of a security
> vulnerability, perception is just as important. While the specific
> technical aspects of this vulnerability would seem to indicate only a
> subset of etags users are actually exposed to this risk, such detail is
> likely to be lost amongst the FUD which tends to accompany security
> issues. 

Would you like to work on preparing an Emacs 28.3 tarball?  The
instructions are in admin/make-tarball.txt and a couple of additional
files to which it points.

TIA

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

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

  > While I understand the resourcing issues, I think this is the wrong
  > decision. We are in the situation where the current released version of
  > Emacs has a known security exploit with a severity classification of
  > high (although this assessment seems to be under review) and the
  > response seems to be "Sorry, we are too busy trying to get the next
  > version released to deal with this".

I agree.  Fixing this one bug seems to be important to our user
community, and we already know the fix.  We should release a fixed
version.

What makes it a ontrivial job to release one?  Is it because there
other fixes have been committed to the Emacs 28 branch since the last
release?  Would including them in a release call for some additioal
work?

If so, I am sure we can find a solution that avoids some of that work.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, emacs-devel@gnu.org
> Date: Thu, 16 Feb 2023 12:50:08 -0500
> 
> What makes it a ontrivial job to release one?  Is it because there
> other fixes have been committed to the Emacs 28 branch since the last
> release?  Would including them in a release call for some additioal
> work?

The whole process takes a non-trivial amount of work.  It is described
in make-tarball.txt.  If someone wants to do it, they are welcome.

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

[Jim Porter]

On 2/16/2023 12:02 PM, Eli Zaretskii wrote:
>> From: Richard Stallman <rms@gnu.org>
>> Cc: eliz@gnu.org, emacs-devel@gnu.org
>> Date: Thu, 16 Feb 2023 12:50:08 -0500
>>
>> What makes it a ontrivial job to release one?  Is it because there
>> other fixes have been committed to the Emacs 28 branch since the last
>> release?  Would including them in a release call for some additioal
>> work?
> 
> The whole process takes a non-trivial amount of work.  It is described
> in make-tarball.txt.  If someone wants to do it, they are welcome.

Would it help to turn make-tarball.txt into an executable script? 
Looking through the document, I believe most of it could be automated. 
Even if we only automated the easiest parts, that would still cut down 
on the amount of manual effort required.

Eventually, we could even use EMBA to produce these tarballs if we can 
get the script to the point where it requires no human intervention. 
Then (assuming permissions are set up properly and some various other 
handwaving), all a maintainer would have to do to publish a new Emacs 
release would be to tag a revision and push the tag to Savannah.

If there's interest in any of this, I'm happy to help work on it.

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

[Eli Zaretskii]

> Date: Thu, 16 Feb 2023 12:41:47 -0800
> Cc: theophilusx@gmail.com, emacs-devel@gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> Would it help to turn make-tarball.txt into an executable script? 
> Looking through the document, I believe most of it could be automated. 

The parts that can be automated are not the ones which make this a
non-trivial job.

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> What makes it a ontrivial job to release one?  Is it because there
>> other fixes have been committed to the Emacs 28 branch since the last
>> release?  Would including them in a release call for some additioal
>> work?
>
> The whole process takes a non-trivial amount of work.  It is described
> in make-tarball.txt.  If someone wants to do it, they are welcome.

(I saw this thread just now.)

Thanks, I'm working on it.  Please see the commits I just pushed to the
emacs-28 branch.  Let me know if you want to inspect the tarball before
I make the release (if so, we could probably coordinate it off-list).

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

[Robert Pluim]

>>>>> On Fri, 17 Feb 2023 02:26:28 -0800, Stefan Kangas <stefankangas@gmail.com> said:

    Stefan> Eli Zaretskii <eliz@gnu.org> writes:
    >>> What makes it a ontrivial job to release one?  Is it because there
    >>> other fixes have been committed to the Emacs 28 branch since the last
    >>> release?  Would including them in a release call for some additioal
    >>> work?
    >> 
    >> The whole process takes a non-trivial amount of work.  It is described
    >> in make-tarball.txt.  If someone wants to do it, they are welcome.

    Stefan> (I saw this thread just now.)

    Stefan> Thanks, I'm working on it.  Please see the commits I just pushed to the
    Stefan> emacs-28 branch.  Let me know if you want to inspect the tarball before
    Stefan> I make the release (if so, we could probably coordinate it off-list).

Your NEWS entry mentions only the CVE, not the other security
fixes. Although we donʼt normally announce bug fixes in NEWS, they
might be worth mentioning.

Robert
-- 

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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 17 Feb 2023 02:26:28 -0800
> Cc: theophilusx@gmail.com, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> What makes it a ontrivial job to release one?  Is it because there
> >> other fixes have been committed to the Emacs 28 branch since the last
> >> release?  Would including them in a release call for some additioal
> >> work?
> >
> > The whole process takes a non-trivial amount of work.  It is described
> > in make-tarball.txt.  If someone wants to do it, they are welcome.
> 
> (I saw this thread just now.)
> 
> Thanks, I'm working on it.  Please see the commits I just pushed to the
> emacs-28 branch.  Let me know if you want to inspect the tarball before
> I make the release (if so, we could probably coordinate it off-list).

Sorry, I don't have time for that now.  The tarball needs to be
test-built on the main platforms we care about, and the diffs against
the Emacs 28.2 tarball carefully eyeballed to make sure nothing is
amiss.  Other than that, you have my blessing.

Thanks!

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> The tarball needs to be test-built on the main platforms we care
> about, and the diffs against the Emacs 28.2 tarball carefully
> eyeballed to make sure nothing is amiss.

Thanks.

I can test the tarball on GNU/Linux and macOS.  Could someone please
volunteer to help test build it on other platforms (such as MS-Windows)?

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

[lux]

On Fri, 2023-02-17 at 06:01 -0800, Stefan Kangas wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The tarball needs to be test-built on the main platforms we care
> > about, and the diffs against the Emacs 28.2 tarball carefully
> > eyeballed to make sure nothing is amiss.
> 
> Thanks.
> 
> I can test the tarball on GNU/Linux and macOS.  Could someone please
> volunteer to help test build it on other platforms (such as MS-
> Windows)?
> 

I can compile normally in Windows 10+MINGW64：

$ uname -a
MINGW64_NT-10.0-19044 lx-windows 3.4.5.x86_64 2023-01-20 09:17 UTC
x86_64 Msys

$ ./emacs/src/emacs --version
GNU Emacs 28.3
Copyright (C) 2022 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

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

[lux]

On Fri, 2023-02-17 at 06:01 -0800, Stefan Kangas wrote:
 
> I can test the tarball on GNU/Linux and macOS.  Could someone please
> volunteer to help test build it on other platforms (such as MS-
Windows)?
>

I build successfully in Windows 10+MINGW64, FreeBSD and OpenBSD.

For Windows 10 MINGW64:

   $ uname -a
   MINGW64_NT-10.0-19044 lx-desktop 3.4.5.x86_64 2023-01-20 09:17 UTC
   x86_64 Msys
   $ ./src/emacs --version
   GNU Emacs 28.3
   Copyright (C) 2022 Free Software Foundation, Inc.
   GNU Emacs comes with ABSOLUTELY NO WARRANTY.
   You may redistribute copies of GNU Emacs
   under the terms of the GNU General Public License.
   For more information about these matters, see the file named COPYING.

For FreeBSD:

   # uname -a
   FreeBSD freebsd 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-
   fc952ac2212 GENERIC amd64
   # ./src/emacs --version
   GNU Emacs 28.3
   Copyright (C) 2022 Free Software Foundation, Inc.
   GNU Emacs comes with ABSOLUTELY NO WARRANTY.
   You may redistribute copies of GNU Emacs
   under the terms of the GNU General Public License.
   For more information about these matters, see the file named COPYING.

For OpenBSD:

   # uname -a                                                         
   OpenBSD openbsd.lan 7.2 GENERIC#728 amd64
   # ./src/emacs --version                                            
   GNU Emacs 28.3
   Copyright (C) 2022 Free Software Foundation, Inc.
   GNU Emacs comes with ABSOLUTELY NO WARRANTY.
   You may redistribute copies of GNU Emacs
   under the terms of the GNU General Public License.
   For more information about these matters, see the file named
   COPYING.

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

[Corwin Brust]

On Fri, Feb 17, 2023 at 8:01 AM Stefan Kangas <stefankangas@gmail.com> wrote:
>
> I can test the tarball on GNU/Linux and macOS.  Could someone please
> volunteer to help test build it on other platforms (such as MS-Windows)?

I created a set of binaries for Windows from the emacs-28-rc1 tarball;
they are on the alpha FTP site, here:

https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-28/?C=M;O=D

I noticed nothing unusual per the 28.1 and 28.2 builds, except perhaps
that the prerelease calls itself 28.3 and not 28.2.90 or such.

I hope these will help others, for whom compiling under Windows isn't
convenient, to help spot any issues. FWIW, it's working fine for me so
far.  It handled startup with my normal config properly, including
connecting to IRC, twitch via IRC, etc.  I'll report any issues I do
find running under Windows.

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

[Michael Albinus]

Stefan Kangas <stefankangas@gmail.com> writes:

Hi Stefan,

> Thanks, I'm working on it.  Please see the commits I just pushed to the
> emacs-28 branch.

I've just realized, that Tramp is counted as version 2.5.4-pre in the
emacs-28 branch. This is incorrect, it must be 2.5.4 (that Tramp version
was released a while ago).

Is it OK, when I change trampver.el and trampver.texi accordingly?

Best regards, Michael.

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

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

  > The whole process takes a non-trivial amount of work.  It is described
  > in make-tarball.txt.  If someone wants to do it, they are welcome.

The steps all need to be done, but what makes them nontrivial is that
normally some of them will run into snags that require nontrivial
corrections.

Maybe it would be good to do this in a Shell buffer and save the
typescript, so a more experienced persion can verify it was done
right.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: theophilusx@gmail.com, emacs-devel@gnu.org
> Date: Sat, 18 Feb 2023 23:47:57 -0500
> 
>   > The whole process takes a non-trivial amount of work.  It is described
>   > in make-tarball.txt.  If someone wants to do it, they are welcome.
> 
> The steps all need to be done, but what makes them nontrivial is that
> normally some of them will run into snags that require nontrivial
> corrections.
> 
> Maybe it would be good to do this in a Shell buffer and save the
> typescript, so a more experienced persion can verify it was done
> right.

That's not the main aspect that makes this nontrivial.  Many steps
described in make-tarball.txt require that a human eyeballs the
results of some commands and/or messages from some commands, and fixes
any problems that need fixing.  The process of examining and the
decision which ones are "worth fixing" is what takes time and effort,
and logging what was done in one case makes the next one no easier.

Another non-trivial part is updating the manuals on the Web site.  The
procedure we use for building the manuals is very fragile and tends to
break with every new Texinfo release.

Anyway, this is all moot point now, since Stefan Kangas already did
the job (for which I thank him again).

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

[Robert Pluim]

>>>>> On Mon, 13 Feb 2023 22:47:07 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> Date: Mon, 13 Feb 2023 12:15:50 -0600
    >> From: Troy Hinckley <comms@dabrev.com>
    >> 
    >> My company will not allow an install of Emacs 28 due to CVE-2022-45939. There is a patch for this in the
    >> master branch, but it did not make it in time for Emacs 28.2. We have many Emacs users who would like to
    >> upgrade to 28. What would be the effort to back port this fix and do an Emacs 28.3 release?

    Eli> Unfortunately, we don't have the resources to produce another v28.x
    Eli> release.  Emacs 29.1 will start its pretest soon, and will have this
    Eli> issue resolved when it is released, hopefully in a couple of months.

    Eli> Alternatively, you could ask the distro which you are using (if you
    Eli> are using a distro) to backport that patch to the Emacs 28 codebase.
    Eli> Or patch the sources yourself and build Emacs, if that is how you
    Eli> produce the binaries.

Or for minimal effort: donʼt install the emacs-28 'etags'

Robert
--