Hacker News Reader

Comment by zrail | Hacker News Reader

I recently refactored my Emacs config[1] to use el-get[2], which lets you install from the official package list from random git repos, and even from the emacs wiki if you're so inclined. My config is quite a bit simpler and easier to back on than it was before.

[1]: https://github.com/peterkeen/dotfiles [2]: https://github.com/dimitri/el-get

View on HN

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.

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".

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?

el-get is pretty cool but I think package has the following advantages over el-get:

1) it's standard emacs

2) although it doesn't have yet it will be able to support digital signatures for packages (as well as other security mechanisms)

As a developer of Emacs packages (it seems to be the only code I've written this year, outside of work) I am sticking with package.

I don't know how much the tips here might be relevant to el-get, I think not very.

el-get is really for picking up the loose ends that don't make it into packages. Most Emacs users should start out with package and only move to el-get if they really need it.

Reply on news.ycombinator.com