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 attachment 155467 [details, diff] 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 attachment 155469 [details] 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
alpha/sparc 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
arm/s390/sh stable
Security, can we assist you in any way bringing out the GLSA? Maybe by reviewing it.
GLSA 200902-06, sorry for the delay...
