Bugzilla Bug 221197

Morten Welinder reports:

By shipping a .flc accompanying an source file (.c for example) and setting
font-lock-support-mode to fast-lock-mode in the source file through local
variables, any Lisp code from .flc is executed without warning.  This happens
in the scope of the user, so no privilege escalation, but no user interaction
needed apart from opening the file.
 This only applies to Emacs 21 which is still supported by Gentoo's Emacs team
and has a stable version.  Emacs 22 and 23 want a confirmation from the user,
while Emacs 18 has no font-locking support at all.

XEmacs seems to be affected, too.  ulm already prepares a patch from what I
heard.

> ulm already prepares a patch from what I heard.

Let's first wait if upstream comes up with a solution.

For XEmacs the bug report is here:
http://tracker.xemacs.org/XEmacs/its/issue378

Patch in http://article.gmane.org/gmane.emacs.devel/97038 for GNU Emacs, will
apply tomorrow.  Should apply to XEmacs as well.

> Patch in http://article.gmane.org/gmane.emacs.devel/97038 for GNU Emacs

This fix is not correct.

From the reply of GNU Emacs upstream I conclude that they consider Emacs 22
only (which is not really affected in the first place).

So here is a patch that will fix the problem for both Emacs 21 and 22:
<http://sources.gentoo.org/viewcvs.py/gentoo/src/patchsets/emacs/21.4/18_all_fast-lock.patch?rev=1.1&view=markup>

Fixed in emacs-21.4-r17. I've also applied the bugfix to emacs-22.2-r2, since
it still contains the affected code, although it is not loaded by default.

Arch teams, please stabilise:
app-editors/emacs-21.4-r17
app-editors/emacs-22.2-r2

> So here is a patch that will fix the problem for both Emacs 21 and 22:

To clarify, this is for Emacs 21:
<http://sources.gentoo.org/viewcvs.py/gentoo/src/patchsets/emacs/21.4/18_all_fast-lock.patch?rev=1.1&view=markup>

For Emacs 22 the hunk for loaddefs.el must be omitted:
<http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-editors/emacs/files/emacs-22.2-fast-lock.patch?rev=1.1&view=markup>

Sorry for the bugspam.

alpha/ia64/sparc stable

I'm still waiting for XEmacs upstream, since the fix would have to be applied
to app-xemacs/edit-utils and that is not a package we can easily patch
ourselves.

Stable for HPPA.

ppc64 stable

x86 stable

amd64 stable

ppc stable

app-editors/emacs-21.4-r17 (and 22.2-r2) stable on all supported arches.

Created an attachment (id=155467) [edit]
Patch for app-xemacs/edit-utils-2.37

Three weeks since this is fixed for GNU Emacs, so we are way behind the time
scale for B2. The bug tracker of XEmacs upstream is still unavailable (why?),
so I'm attaching a patch for app-xemacs/edit-utils-2.37 here.

The changed files must be byte compiled, for example by doing:
        ${XEMACS_BATCH_CLEAN} -f batch-byte-compile \
                fast-lock.el auto-autoloads.el || die "batch-byte-compile
failed

However, I don't know what is the recommended method for doing this within the
framework of xemacs-packages.eclass. That "unpack" is only called in
src_install doesn't really ease this task.

Created an attachment (id=155469) [edit]
edit-utils-2.37-r1.ebuild

Ad-hoc ebuild. It works, but is very clumsy, so I think there must be an easier
or more elegant way.

graaff, please advise.

XEmacs' bug tracker is down due to disk problems, as far as I can tell. No news
on this security issue either.

If we must bring out our own edit-utils version I would prefer to build a
package similar to the one from upstream, i.e. use the packages CVS to build a
new package and distribute the .el and .elc files.

While your ebuild may work it may also miss some compatibility issues. For
example, all upstream packages are built with xemacs 21.4 because the bytecode
generated by 21.5 can't be read by 21.4 in all cases. By compiling things like
this we may risk a bunch of subtle bugs...

Unfortunately my time to work on Gentoo at all right now is very very
limited... maybe I will have some time to look at this in the weekend.

(In reply to comment #15)
> Created an attachment (id=155467) [edit]
> Patch for app-xemacs/edit-utils-2.37

This has been accepted by XEmacs upstream:
<http://cvs.xemacs.org/viewcvs.cgi/XEmacs/packages/xemacs-packages/edit-utils/ChangeLog?rev=1.232&content-type=text/vnd.viewcvs-markup>

Since xemacs upstream's package manager is currently awol and none of the other
devs seem to want to build a new package, I've just created a new xemacs
package for edit-utils myself. Hopefully this works as expected...

app-xemacs/edit-utils-2.39 contains the patches that Ulrich linked to. I'd like
to keep this in testing for at least a week to see if problems crop up,
especially since I've packages things myself this time.

No reported bugs on the new package, and I've been using it myself in the last
week on both amd64 and x86, so I think we are ready to stabilize:

app-xemacs/edit-utils-2.39
app-xemacs/xemacs-packages-all-2007.04.27-r1

The latter is a meta-package that makes sure the new version of edit-utils is
pulled in. ppc64 doesn't have this keyworded at all, so it can just be left
as-is.

Adding architecture teams to CC.

Target keywords:
app-xemacs/edit-utils-2.39: alpha amd64 ppc ppc64 sparc x86
app-xemacs/xemacs-packages-all-2007.04.27-r1: alpha amd64 ppc sparc x86

And, as a reminder:
app-editors/emacs-21.4-r17: arm s390 sh
app-editors/emacs-22.2-r2: arm s390 sh

x86 stable

ppc64 stable

alpha/sparc stable

amd64 stable

ppc stable

2008.0 is out, so no need to keep release on the CC list.

app-editors/emacs:
Vulnerable versions: <22.2-r2
Unaffected: >=22.2-r2, revision >=21.4-r17, <19

app-xemacs/edit-utils:
Vulnerable versions: <2.39
Unaffected: >=2.39

Friendly reminder, after three more months. The following keywords are still
missing:
app-editors/emacs-21.4-r17: arm s390 sh