Dear, Thank you to point me out explanations about the issue that you are trying to address. They are mentioned in the DPN but I have not carefully read them.
However, I am still not sure to understand the aim, and if the effort will pay off. Firstly, because some of these security issues are partially fixed by Emacs 25.1, if I understand well. Then, I am sure they will be fixed Emacs-side soon, I guess. Maybe not so soon for e.g., the package signature or other fancy Debian-package features ; whatever. Therefore, from my point of view, the aim of a such tool corresponds more to the use of all the Debian infrastructure (well-integration, reproducibility, stability and "long-term" support, etc.). From what I understand, it is the same sort of idea for Emacs-packages than for Python-packages, R-packages, Perl-packages, etc. Each of them has its own package manager working more or less efficiently, and they are still packaged by Debian. And it is not necessary about security reasons. All this package effort, is it not the same aim ? Secondly, the need of administrator privileges to install `elpa-*` packages is --from my point of view-- a drawback. But, it is a not drawback of `elpa-*` package, it is a drawback about APT. From what I am daily doing, it appears to me really useful to be able to locally "install" programs and/or libraries such that scientific tools, editing tools, etc., without querying the sysadmin of the lab (justifying why? depending on his/her planning, etc.). For my daily tasks, `conda` package manager fits my needs, even if it lacks clear rules for packing, and share nothing between users, which does not save disk memory. I mean, the Nix/Guix approach seems interesting, and more than only this "relocable trick", e.g., http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/seeing_Debian_through_a_Functional_lens.webm Whatever! It is out of topic... :-) I suppose that `#debian-emacs` if the entry point for helping ? (note this channel is not mentioned on the Wiki page: https://wiki.debian.org/IRC ) All the best -- simon On 2 December 2016 at 21:40, Sean Whitton <[email protected]> wrote: > Hello Simon, > > On Fri, Dec 02, 2016 at 11:50:11AM +0100, zimoun wrote: >> One of the main advantage of `package.el` combined to `use-package` is >> that it works without any administrator privileges. Therefore, I can >> use some exotic add-ons on my lab computer without querying the always >> busy sysadmin. (that's why I am also using `conda` or `cRan` and I am >> testing Guix, whatever!). > > Yes, but when package.el downloads packages from the Internet it does so > in an insecure manner: > > https://glyph.twistedmatrix.com/2015/11/editor-malware.html > https://github.com/melpa/melpa/issues/2342 > > This is what we are trying to avoid. package.el is just not very safe > yet. > >> I did not find too much information, so my question is: the idea >> behind such tools and the aim of `elpa-*` packages is to add Debian >> infrastructure to (M)ELPA, keeping the flexibility of `package.el` ? >> I mean, is it possible to install `elpa-*` package without >> administrator privilege ? e.g., with the option `:ensure t` of >> `use-package` ? Or before I need to install system-wide the `elpa-*` >> package by APT tools ? > > No, installing elpa-* packages requires administrator privileges. > > -- > Sean Whitton
