Re: dh-make-elpa ?
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 <spwhitton@spwhitton.name> 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
Reply to: