+++ This bug was initially created as a clone of Bug #398227 +++
From the emacs-devel mailing list:
"Hiroshi Oota has found a security flaw in EDE (part of CEDET), a development tool included in Emacs. EDE can store various information about a project, such as how to build the project, in a file named Project.ede in the project directory tree. When the minor mode `global-ede-mode' is enabled, visiting a file causes Emacs to look for Project.ede in the file's directory or one of its parent directories. If Project.ede is present, Emacs automatically reads and evaluates the first Lisp expression in it.
This design exposes EDE users to the danger of loading malicious code from one file (Project.ede), simply by visiting another file in the same directory tree."
Most likely this affects app-xemacs/ede too.
Filed upstream: http://tracker.xemacs.org/XEmacs/its/issue825
@ Maintainer(s): Looks like app-xemacs/ede was forgotten while bug 398227 was fixed. =app-xemacs/ede-1.03-r1, the latest version in repository, is still vulnerable:
# grep 'ede-version' /var/tmp/portage/app-xemacs/ede-1.03-r1/image/usr/lib/xemacs/xemacs-packages/lisp/ede/ede.el
(defconst ede-version "1.0pre4"
So please apply commit 2a5135c50e212ae4ddade40c9704e396e01559ca from cedet repository, use https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-emacs/cedet/files/cedet-1.0-ede_security_fix.patch or copy files from cedet.
Or is it time to call tree cleaners? Please tell us how you want to proceed!
There is app-xemacs/ede-1.06 in the emacs overlay. Not sure if the bug is fixed in that version (I cannot download it because ftp.xemacs.org is currently down).
No the bug is not fixed in that version. XEmacs package maintenance can fool you by having its own version numbers that tracks the releases as part of the xemacs package tree. Version 1.06 is actually upstream version 1.0pre4.
It could still have been patched but from looking at the bitbucket repo it does not look that way. https://bitbucket.org/xemacs/ede
So I will look into applying the patch.
About xemacs.org. That is a sad story. It has been down since around August 2016 and it is unclear when it will be brought back online again. I have heard of initiatives to bring it up again but who knows when if ever. This means that the ebuild for xemacs now relies on that the packages are fetched from the mirrors. I don't know what impact that has on xemacs as a Gentoo package. I realize that it of course not is good that the upstream archive is dead but as long as the gentoo mirrors keeps the same archives we could still live with that, or do I need to take action on that as well?
Unfortunately applying the patch is easier said than done since the XEmacs packages essentially are binary packages that are just unpacked by the ebuild. The proper solution keeping that framework would be to get the patch into the upstream archive. This is unfortunately not possible at the moment since upstream infrastructure is down.
There is however hope that this will be fixed soon since the xemacs homepage recently been brought to life. I'm having a dialog with upstream on this issue.
Is there any news about the patch? The upstream is online
I have had no luck so far I'm afraid: https://email@example.com/message/T736WWQCTQS5OIS2MHAFLVMGSOIPNZBG/
I will escalate further and try to speed it up.
I have had no luck in getting in contact with upstream although I have tried multiple times and in different forums. I have thus masked the package and its dependencies in profiles/package.mask.
I'm still having some hope for getting in contact with upstream so I'm not going to announce these packages for removal, yet.
Has upstream gotten back to us on this. I believe we could perform a final rites on this package.
Gentoo Security Padawan
I have talked to the upstream developer who plans to update the package in the beginning of June (This year!). If that happens we should be able to unmask the packages. If that does not happen I'll be happy to perform a last rites on this and the dependent packages.
Also, I completely fail to understand why old versions of the packages are masked and kept when new versions are unmasked.
If you are referring to the masked packages:
Their updated versions were stabilized as of yesterday so I have not had the opportunity to clean up jet. My plan is to remove those and then remove the mask.
Please advice if I could have handled that differently and better.
The bug has been referenced in the following commit(s):
Author: Mats Lidell <firstname.lastname@example.org>
AuthorDate: 2018-12-03 21:01:01 +0000
Commit: Mats Lidell <email@example.com>
CommitDate: 2018-12-03 21:01:01 +0000
package.mask: unmask app-xemacs/ede with dependencies
Security issue is fixed
Signed-off-by: Mats Lidell <firstname.lastname@example.org>
profiles/package.mask | 12 ------------
1 file changed, 12 deletions(-)
(In reply to Larry the Git Cow from comment #14)
> The bug has been referenced in the following commit(s):
> commit 98637c4c3839d525d3cffb7cfd2f294f1128f0a9
> Author: Mats Lidell <email@example.com>
> AuthorDate: 2018-12-03 21:01:01 +0000
> Commit: Mats Lidell <firstname.lastname@example.org>
> CommitDate: 2018-12-03 21:01:01 +0000
> package.mask: unmask app-xemacs/ede with dependencies
> Security issue is fixed
> Bug: https://bugs.gentoo.org/398241
> Signed-off-by: Mats Lidell <email@example.com>
> profiles/package.mask | 12 ------------
> 1 file changed, 12 deletions(-)
Mats, so which version actually contains the fix?
The fix is provided by upstream in app-xemacs/ede-1.07.
This issue was resolved and addressed in
GLSA 201812-05 at https://security.gentoo.org/glsa/201812-05
by GLSA coordinator Aaron Bauman (b-man).