4 ms·

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 o

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.

zrail 14y ago
Wow, that's a good point. I'm going to pull the stuff I use directly into my dotfiles repo.
- heretohelp 14y ago
  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.
- nic-ferrier 14y ago
  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".
sanityinc 14y ago
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.
nic-ferrier 14y ago
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.
- burke 14y ago
  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.
  - nic-ferrier 14y ago
    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?

zrail 14y ago

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

heretohelp 14y ago
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.
nic-ferrier 14y ago
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".

sanityinc 14y ago

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.

nic-ferrier 14y ago

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.

burke 14y ago
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.
- nic-ferrier 14y ago
  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?