[Top][All Lists]

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

Re: Fwd: Should package.el support notifying on package security updates

From: Tim Cross
Subject: Re: Fwd: Should package.el support notifying on package security updates?
Date: Fri, 12 Aug 2022 10:29:22 +1000
User-agent: mu4e 1.8.8; emacs 29.0.50

Matt Armstrong <matt@rfc20.org> writes:

> Gulshan Singh <gsingh2011@gmail.com> writes:
>> I recently reported a security issue for a package on MELPA, where
>> even though I trusted the package author, if I used the package to
>> process untrusted data that data code be crafted in a way to execute
>> arbitrary code on my system. This led me to wonder if there was any
>> mechanism for package.el to distinguish between regular updates and
>> security updates, and I wasn't able to find any information on this.
>> Has there been any past discussion on this? As an example, on Ubuntu you
>> can see how many of the pending updates are security updates as opposed
>> to regular updates, and you can configure the system to auto-update just
>> the security updates. I feel like the package manager in emacs should
>> have something similar, but maybe I'm missing something about why this
>> functionality isn't included.
> I am not an authority on Emacs packages, but as far as I am aware, there
> is no mechanism in place to track security vulnerabilities in Emacs
> packages or any way to urgently present available fixes to users
> (e.g. by suggesting a partiular package upgrade is urgent).
> One substantive discussion I found on package security issues in general
> occurred on emacs-devel 9 years ago:
> Subject: security of the emacs package system, elpa, melpa and marmalade
> Date: Mon, 23 Sep 2013 09:30:35 +0200
> https://lists.gnu.org/archive/html/emacs-devel/2013-09/threads.html
> Shortly after that discussion it looks like package.el was changed to
> verify package signatures (at least optionally, based on the
> availability of a gpg installation, which went through refinement over a
> period of years).

While I don't disagree with the underlying principal, I suspect it would
likely add additional complexity which will end up being of little
actaul benefit. This is for two reasons

- There are actually very few security issues reported for Elisp
  packages. This doesn't mean there aren't any, only that they are
  discovered and reported very rarely.

- It would require package maintainers to somehow flag that an update is
  a security update rather than just a standard update. As it is already
  somewhat challenging to get many package maintainers to include
  consistent change logs in their packages, I suspect then also asking
  them to distinguish security updates from normal updatges may be
  asking too much.

I think the big difference with the Emacs package ecosystem from Ubuntu
(and other GNU Linux distributions) is that there is no central
authority managing package releases. With Ubuntu, there is a team who
are responsible for the maintenance and release of all core Ubuntu
packages. This brings a level of consistency which is difficult to
achieve with Emacs where many packages are managed by individuals and
separate groups (especially when it comes to MELPA). The breadth of
packages included in a distribution also results in packages which have
more frequent security issues discovered (possibly due to different size
in user base, different type of application or inherently higher
security risk). 

I suspect if we added the functionality to flag an update as a security
update, it is something which happens so rarely, nobody will use it and
when they do, nobody will recognise what it really meant. All that will
really be achieved is a more complicated system, potentially adding more
bugs (possibly even security issues!). 

reply via email to

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