Re: security of the emacs package system, elpa, melpa and marmalade

["Stephen J. Turnbull" <stephen@xemacs.org>]

Matthias Dahl writes:

 > Maybe this is just wishful thinking but what if we could channel that
 > effort into a single and package repository independent project?
 > 
 > Please let me explain: The project would mostly build on the web of
 > trust principle. Basically people can review and rate packages. And in
 > order to do so, you need a certain level of trust which you gain through
 > ratings or pledges from already trusted reviewers. Initially those could
 > be the Emacs and respective package maintainers and so forth.

It could work.  After all, people do write documentation. :-) And this
is something a few non-programmers (a mostly untapped resource) could
put a lot of effort into, because at least at startup there will be a
lot of admin and advocacy to be done.  Design of the metrics is going
to be an ongoing effort.  The idea of having it be a separate project
means that XEmacs and SXEmacs people can get into the act to some
extent.

However, there is at least one point where your argument is not so
strong.  And that is that (as a sysadmin) I don't review *any* Emacs
code---it's not "mission-critical" on those hosts where I care about
Emacsen security.  People who suffer from my style of paranoia have to
reduce the complexity of their environments, or they won't get
anything else done.  I suspect that outside of the core development
community there are few doing much reviewing.  Also, package
maintainers really shouldn't be trusted initially, because there are
folks who have been maintaining their packages for decades but nobody
really knows them.  Of course, those well-known to core can be added
to the trusted group immediately.

Specifically, with respect to Emacsen, I trust that core changes to
XEmacs get reviewed by the reviewers, and on "exposed systems" I use
use nothing but what XEmacs calls "core Lisp" plus the "xemacs-base"
and "text-modes" packages (and "text-modes" is stripped of libraries I
don't use).  It's a minimal configuration useful for viewing logs and
maintaining configuration files, and the release is several years old.
(XEmacs 21.4.20 -- but Emacs 18.55 would probably do just as well!
Not quite, I do need to be able to decode and display non-ASCII, but I
don't currently ever need to edit it.)  But Gnus, calendar, and
jedi.el just aren't even installed on such hosts.  I suppose some
people in my position would also install org-mode, but I haven't
caught that bug.