2013-01-23 Security of Code Downloaded from Online Sources

In the anonymous rant The Wikemacs Experiment: 300 Days Later, the author claims “The biggest problem is that it is *insecure*. [...] Anyone can edit any of the pages that contain Elisp code.” The same sentiment was expressed by Alex Bennée in a comment on Google+: “What is really needed is a way to be sure that the source for the emacs extension your updating hasn’t been subverted by someone else with ill intent.”

The Wikemacs Experiment: 300 Days Later

in a comment on Google+

I said:

Experiences and ideas of “what is really necessary” vary. As for myself, I’ve installed code from all over the Internet without reviewing the source. Installing it from a gist or git repo is hardly a different experience. If you want to figure out whether a source is trustworthy, you do the usual things: do people link to the code, how long has it been around, what about recent checkins, that sort of thing. Or you get into the crypto business of signing releases.
You could of course say that every day that passes without a problem increases our false sense of security... I have no answer to that. All I can say is that if security is your problem, using gists and github is not the solution (as you say yourself). The source of the insecurity is our habits, our culture of downloading and installing anything and everything. I’m not sure how you’ll ever make sure “that the source for the emacs extension your updating hasn’t been subverted by someone else with ill intent.” That seems pretty impossible to me unless you limit yourself to the core Emacs distribution (and even that’s not a guarantee).
People on the #emacs channel keep asking “is there way to do X” and thus my impression is that *finding* stuff is a more pressing problem. I feel that encouraging people to create a page on the wiki saying “here is code to help you do something” is the solution to that problem.
But then again, I guess we all differ in what we consider to be the most pressing problem.

#emacs channel

Alex Bennée the correctly points out that using “a user locked solution like a gist or git repo you can at least be assured what you���re installing has come through one person who you’ve trusted to a degree before.” I guess that’s true. We’ll see whether people start switching over to using gists instead of editing wiki pages. I said in an earlier comment:

I added gist support [...] because it was easy to do, not because it will encourage existing authors to move their elisp code on wiki pages to github. If at all, it might encourage future elisp authors to transclude a gist... But then again, there’s nothing preventing them from linking to a gist right now. Perhaps it’s also a generational thing. People that have been living without github and gists don’t feel a particular need to start using it.

Interesting times. 😄

​#Web ​#Security ​#Emacs ​#Wikis

Comments

(Please contact me if you want to remove your comment.)

Hi Alex,

first of all - thank you very much for Oddmuse! I’m using it for both my personal site and Department's site. It has some rough edges, but overall I find it a very nice tool, and I did recommend it to a few people.

personal site

Department's site

Now to the point: I was just wondering whether it might be a good idea to use stackoverflow with [emacs] tag (which you mentioned in your earlier post), or maybe even start something like emacs.stackexchange.com? I’m not sure whether it could solve any problems you mentioned, but (at least for the more paranoia-oriented people) it might feel a bit more secure, with all the comments, up- and downvotes etc. I don’t know. (Personally, I didn’t use any actual *code* from Emacswiki, but I guess it would not be a huge problem for me.)

– mbork 2013-01-23 20:55 UTC

mbork

---

Nothing has really changed. Previously, Lisp code was shared between a few Emacs hackers and the intention was to work on improving it and get it integrated into Emacs. The GNU Project was the trusted authority. They distributed the useful contributions. Obviously, that hasn’t scaled well. I think it’s perfectly reasonable for Emacs newbies to distrust code they can’t read that was written by hackers they don’t know.

– AaronHawley 2013-01-23 21:56 UTC

AaronHawley

---

Thank you for the kind words, Marcin. I think a lot of people are already using Stackoverflow for Emacs questions. I find the site incredibly useful when I’m at work (except my work is hardly ever related to Emacs, unfortunately).

using Stackoverflow for Emacs questions

I also agree with Aaron. Good point regarding the GNU Project being the trusted authority.

– Alex Schroeder 2013-01-23 22:39 UTC

Alex Schroeder

---

I’ve collected examples of manipulated code or binaries: http://www.koch.ro/blog/index.php?/archives/153-On-distributing-binaries.html

http://www.koch.ro/blog/index.php?/archives/153-On-distributing-binaries.html

I don’t think that it’s too hard to get a gpg key, go to a signing party on your next software conference and sign all your releases. It’s rather dumb easy. And you can use signed git tags on github or any other git hosting platform to provide a very strong confidence for your user that they can trace you back in case you provided bad code.

– Thomas Koch 2013-01-24 12:57 UTC

Thomas Koch

---

True, it is not “too hard” for many people. But when I write a little throw-away piece of code like EmacsWiki:1000 Words it’s a bit much to ask. I’ve never been to a key signing party. I never go to software conferences. I post it on the wiki. And when I write another little piece of code, I do it again. That’s why *my* code ends up on the wiki and not on github. I keep hoping people will volunteer to maintain code I wrote and either add it to Emacs itself or maintain it in decent repositories. I just don’t see myself doing it. I *like* the division of labor between programming and packaging.

EmacsWiki:1000 Words

– Alex Schroeder 2013-01-25 10:24 UTC

Alex Schroeder

---

It might be a bit too much to sign a little script of 10 lines that I can quickly review. I was rather referring to big software projects. However once you’ve got a gpg key you can sign a small code snippet just as easily as you can sign an email.

– Thomas Koch 2013-01-26 10:11 UTC

Thomas Koch

---

I think now the discussion turns to the question of where to draw the line. There’s exactly one large project that is exclusively hosted on Emacs Wiki, I think: EmacsWiki:Icicles. Others, such as EmacsWiki:Anything moved to github. Other, like EmacsWiki:Gnus or EmacsWiki:BBDB were never hosted on Emacs Wiki to begin with. Then there are the large collection of inofficial extensions like the ones listed on EmacsWiki:rcirc. Do they count as a single project or is each file a separate one? From my point of view, each one is a separate project. I just use two of them myself. As such, they are not really “a little script of 10 lines” but they don’t feel like big software projects, either.

EmacsWiki:Icicles

EmacsWiki:Anything

EmacsWiki:Gnus

EmacsWiki:BBDB

EmacsWiki:rcirc

I think I’m with Aaron. Emacs Wiki mostly hosts code on the wiki that one could view as “incubator” stuff. Things that haven’t made it into their own repositories or that haven’t made it into Emacs itself. Thus, asking for version control and signed releases is—in the context of code hosted on Emacs Wiki—asking for the right thing at the wrong time. It’s premature for those small single file projects that are hanging in Limbo somewhere between ten lines and inclusion into Emacs or indendence as their separate projects.

– Alex Schroeder 2013-01-26 11:46 UTC

Alex Schroeder

---

Using El-Get you can easily add a checksum in your setup so that you only automatically get code from EmacsWiki with that checksum. So if you get to a new machine or re-install your Emacs setup from scratch, and the newly downloaded EmacsWiki code does not match your checksum, El-Get will refuse to load it for you. You can get the checksum interactively using M-x el-get-checksum command.

EmacsWiki

EmacsWiki

– dim 2013-01-27 21:13 UTC

dim

---

Excellent feature!

– Alex Schroeder 2013-01-28 07:23 UTC

Alex Schroeder