9

I'm looking at emacs helm specifically, which has the following properties:

  • it has thousands of commits
  • it is largely maintained by one user
  • the maintainer has no other profiles (social media, etc.) I was able to find on a few searches
  • it is actively maintained (today)

Since I'm about to install arbitrary code on my computer to use in my text editor, I wanted to verify if this has undergone any review process. I'd like to say "well it's open source" but I really am far from the elisp ability to audit all the code myself. I would like to assume others in the community have reviewed it but one that's probably false, and two there are up-to-the-minute commits. Are there other strategies I am missing?

For the record the vector is simple: "open source" doesn't matter all that much if the contributor is working under a throwaway account, or if there's no review process.

Improve this question
7
  • 6
    "Verify" is a big word. In the regular sense of the word, I think the answer is, "You don't (you can't)." You can follow the development activity for a library, and you can check digital signatures and such, but there is nothing that is sure and certain, I believe.
    – Drew
    Commented Apr 1, 2015 at 18:29
  • 3
    Good question. FWIW, code that comes with Emacs is reviewed (via the emacs-diffs mailing-list), but if some contributor were to add a security hole, I'm sure he'd be able to do that without being noticed. Of course, I'd be surprised if there aren't already lots of large accidental security holes in Emacs anyway, so I'm not sure how much of a problem this might be. So I think in order to be able to get a more re-assuring answer, one needs to focus on specific a simple threats (e.g. it should be fairly easy to check if the code performs some kind of non-hidden surveillance).
    – Stefan
    Commented Apr 2, 2015 at 1:00
  • 2
    The maintainer is active on emacs devel for many years, which can be verified with a search, so this is some assurance: lists.gnu.org/archive/cgi-bin/…
    – Tom
    Commented Apr 2, 2015 at 8:28
  • 1
    @Stefan, I was thinking of only a spot check. From my point of view, mapatoms could be put into the "dangerous" group together with start-process, eval and funcall. Of course there would be some false positives, but if the package doesn't use any of those functions, it can be marked as harmless with large certainty.
    – abo-abo
    Commented Apr 2, 2015 at 13:29
  • 1
    You need to add the new make-process, as well as call-process, dbus-<foo>, make-network-stream, and then vc-do-command, vc-git-command, .... And if you put eval and funcall in the "dangerous" category, then most/all packages are dangerous.
    – Stefan
    Commented Apr 2, 2015 at 14:13

1 Answer 1

Reset to default
7

The short answer is unless you read through the code yourself you are taking a lot on trust. Having said that trusting a project sourced from an upstream SCM is a little safer than one which has been pulled directly from the Emacs Wiki for example. However fundamentally you are trusting the author of the package not to turn evil and abuse the ability to run arbitrary code under your Emacs session.

There are some things that may make you feel safer:

  • Stick to popular packages

While popular packages don't automatically get more review the fact they have more users mean the chances of malicious behaviour being detected before it affects you increases.

  • Look at the code metrics

On github you can get a fairly good view of the projects contribution history. Even if the principle author makes most of the commits having a wide range of authors shows there are other people with an active interest in the stability and effectiveness of the code.

  • Prefer GNU ELPA and MELPA Stable to repositories tracking HEADs (MELPA) or allowing un-vetted submissions (Marmalade)

While living on the bleeding edge has a certain appeal for those who want the latest shiny features it does mean you might be the first to accept the latest commit into your environment. Even if not malicious you may well get a package in a state of flux while an "official" release will of least had some sort of cursory review. For example GNU ELPA packages will only get committed by those emacs-devel users with commit rights.

Ultimately I'm sure there will at some point be a security breach via the package system even if it is only a proof of concept experiment. That will be the point you may have to rely on your regular backups.

Improve this answer
6
  • 1
    Marmalade is a poor archive when it comes it “trust”. It allows anyone to upload any packages under any name, with zero verification or review. And it's not exactly well-maintained (just look at the number of open issues).
    – user227
    Commented May 28, 2015 at 16:10
  • @lunaryorn: good point, I'll amend the answer.
    – stsquad
    Commented May 28, 2015 at 18:06
  • @lunaryorn MELPA has even more open issues than the elmarmalade repository, so I doubt this is an usable metric.
    – wasamasa
    Commented May 28, 2015 at 18:28
  • @stsquad The only thing MELPA Stable gives you is tagged releases of things that would have ended up in MELPA anyways, so I don't see how that's safer than using Marmalade.
    – wasamasa
    Commented May 28, 2015 at 18:29
  • 1
    @wasamasa Sorry, my comment was phrased poorly. The number doesn't tell much, for sure, but the open issues are telling: There is zero reaction on new issues, no comments, not even labels or assignments. Marmalade is effectively dead.
    – user227
    Commented May 28, 2015 at 20:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.