unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: emacs-devel@gnu.org
Subject: Re: Fwd: Should package.el support notifying on package security updates?
Date: Fri, 12 Aug 2022 10:29:22 +1000	[thread overview]
Message-ID: <86y1vul261.fsf@gmail.com> (raw)
In-Reply-To: <87y1vus4xy.fsf@rfc20.org>


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	other threads:[~2022-08-12  0:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87r12qm4q5.fsf@gmail.com>
2022-08-08  1:46 ` Fwd: Should package.el support notifying on package security updates? Gulshan Singh
2022-08-12  0:04   ` Matt Armstrong
2022-08-12  0:29     ` Tim Cross [this message]
2022-08-12 13:18       ` Stefan Kangas
2022-08-13  0:44         ` Tim Cross
2022-08-12 21:40       ` Stefan Monnier
2022-08-13  0:58         ` Tim Cross
2022-08-13  4:58           ` tomas
2022-08-13 14:00             ` Stefan Monnier
2022-08-14  3:23     ` Richard Stallman
2022-08-14  3:29       ` Gulshan Singh
2022-08-16  2:52         ` Richard Stallman
2022-08-25  3:32         ` Richard Stallman
2022-08-25  4:33           ` Tim Cross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86y1vul261.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).