Hacker News Reader

Comment by mechanical_fish | Hacker News Reader

I had el-get installing stuff from emacs wiki until someone pointed out that it's completely insecure. Anyone who edits the wiki can inject arbitrary commands on your machine.

The only safe way to use emacs wiki code is to audit it first, and el-get can't do that for you.

View on HN

There are various insecurities in the existing package ecosphere; e.g., provided a package X does not currently exist on Marmalade, anyone can upload a possibly-doctored version of X and make it available for installation. There's often no way to involve the upstream author directly, because many of them don't use or care about ELPA, and many are simply unresponsive.

A robust process for auditing packages is going to be hard to establish. In practice most developers seem to be happy to install any and all updates as long as they're reasonably sure they came from the original author. By using verified upstream source repositories both el-get and MELPA ensure this is the case, as long as one steers clear of libraries originating from the EmacsWiki.

Of course this is true. But it's also true of everything. APT, YUM, GEM, PYPI, anything where there is contributed code and you can't take legal action against someone.

Emacs is no different.

Managed repositories are actually quite a bit different, since the requirements to edit emacs-wiki are quite a bit less stringent than those to submit a modification of someone else's package to a repository.

Apt, Yum, etc., require trust in the repository infrastructure and those select few with write access to a given repository. Emacs Wiki requires trust in the entire internet.

But we're not talking about that, as I said elsewhere, MELPA can have quite strict requirements (only the people allowed to commit to the github project of a repo can make a change, seems fair enough) and marmalade is aiming towards digital signatures. This would make marmalade the same as any other repository with low code review. How much do Debian people code review before a package goes into APT? or CentOS people?

Wow, that's a good point. I'm going to pull the stuff I use directly into my dotfiles repo.

hits the stop button on a stopwatch

And now people realize why I'm a luddite and just keep all my dependencies rolled into my dotfiles repo directly and have done so for years.

Again, that's why we want to add signatures to packages. This is probably always going to be a two tier system though (some people are likely to not add a signature). There are other possible security systems as well, like MELPA could use github and say "yes, this package is authorative from there".

Reply on news.ycombinator.com