[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: security of the emacs package system, elpa, melpa and marmalade

From: Matthias Dahl
Subject: Re: security of the emacs package system, elpa, melpa and marmalade
Date: Mon, 30 Sep 2013 17:25:06 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0

Hello Stephhen...

> Sure.  *Preventing* that is going require doing something that is
> probably impossible for any program that isn't an operating system in
> control of the machine.

I am not saying a sandbox is the best solution. But imho, something
should be done... or would be nice to have. Even if it is community
based reputation system.

>  > You wouldn't work as root on your system, would you?
> I do every day, to run emerge --update. ;-)

Ah, a fellow Gentoo user. ;) Running system updates as root is one
thing, working as root as daily routine where those privileges are just
not required, is careless (for many reasons), to say the least. And I
guess that is not would you do. :)

> The interesting question is, "why should a plugin be denied the rights
> it needs when those go beyond reading the buffer it was invoked from?"

Who said it should get those privileges denied? If it was installed and
declared its required permissions, it will get those. Or am I missing
something obvious from your statement/question here?

> Sure.  But the chances are pretty good that I would.  Anyway, the
> definition of "absolutely need" is "I'm willing to bet that I or some
> other user would catch it even if the author doesn't."

So you check the source for the plugins you use with each new update? Or
who else would you notice malicious code?

And if a plugin is driver by a single author, chances are that something
can go unnoticed for a while if the target group of said plugin is not a
very technical one... and as I learned in this thread, there are many
more Emacs users with a non-technical background.

> There's another answer based on the details of your example.  I avoid
> doing development on exposed hosts.  In one sense that's unfair, but
> in another it goes to the heart of the matter.

Which shows, you care about security too and take preventive measures.
Unfortunately, not everybody can work that way for various reasons, though.

So long,

Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu
 services: custom software [desktop, mobile, web], server administration

reply via email to

[Prev in Thread] Current Thread [Next in Thread]