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

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

[Gulshan Singh]

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

Hi,

I sent the below message to the help-gnu-emacs mailing list, but I wanted
to also raise the same question on the emacs-devel list, as it's more
related to potential feature improvements in emacs.

---------- Forwarded message ---------
From: Gulshan Singh <gsingh2011@gmail.com>
Date: Tue, Jul 12, 2022 at 1:54 PM
Subject: Should package.el support notifying on package security updates?
To: <help-gnu-emacs@gnu.org>


Hi,

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.

[-- Attachment #2: Type: text/html, Size: 1639 bytes --]

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

[Matt Armstrong]

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).

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

[Tim Cross]

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!). 

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

[Stefan Kangas]

Tim Cross <theophilusx@gmail.com> writes:

> - 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.

If they are rare, that doesn't make them less important.

> - It would require package maintainers to somehow flag that an update is
>   a security update

I find the maintainers of important packages to be highly conscientious
people, and that goes in particular the GNU ELPA maintainers.  So I
don't share your concerns.

> 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.

I think people will know the meaning, because it will presumably say
"security update" somewhere.

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

[Stefan Monnier]

> - 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.

Agreed.
And I suspect that security issues are much more common than are reported.
[ Lots of Emacs packages are written under the implicit assumption that the
  current buffer contains something mildly-trustworthy.  ]

> - 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'm not sure it would be a big problem.  But I'm not sure it would be an
improvement either.  Especially because I suspect it might give the
false impression that the code of ELisp packages is somewhat
security-conscious, whereas in my experience, the vast majority of Emacs
packages isn't (they may end up secure by accident, of course).


        Stefan

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

[Tim Cross]

Stefan Kangas <stefankangas@gmail.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> - 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.
>
> If they are rare, that doesn't make them less important.
>

and at no point did I imply they were. 

>> - It would require package maintainers to somehow flag that an update is
>>   a security update
>
> I find the maintainers of important packages to be highly conscientious
> people, and that goes in particular the GNU ELPA maintainers.  So I
> don't share your concerns.
>

It has absolutely nothing to do with whether the maintainers are
conscientious or not. My comments are in no way a criticism of
maintainers. In fact, my comments are in support of maintainers in that
they are arguing against adding additional complexity for something
which happens rarely and which would be difficult to achieve in a
consistent manner because of the distributed maintenance model and how
difficult it is to get consistent work flows when you have a branch that
is only used extremely rarely. 

>> 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.
>
> I think people will know the meaning, because it will presumably say
> "security update" somewhere.

I think you missed my point, but no matter. If you feel it is
worthwhile, go ahead an implement it and get all the maintainers to use
it. If I'm wrong, that is great as it would not be a bad thing to
have. I just think the value it will add is far less than the effort it
will take to build and maintain and in 12 months, no maintainers will
use it because it will be such a rare work flow, they will forget. 

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

[Tim Cross]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>
> I'm not sure it would be a big problem.  But I'm not sure it would be an
> improvement either.  Especially because I suspect it might give the
> false impression that the code of ELisp packages is somewhat
> security-conscious, whereas in my experience, the vast majority of Emacs
> packages isn't (they may end up secure by accident, of course).
>
>

That is an extremely important point. Very few people even gives this a
thought when installing packages - especially packages from MELPA and
other external repositories. Having 'security' would imply for some that
there is a formal security process for reviewing, tracking and reporting
security issues. We don't have any of this and advertising some updates
as security fixes could well create a false sense of security. 

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]

On Sat, Aug 13, 2022 at 10:58:40AM +1000, Tim Cross wrote:
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >
> > I'm not sure it would be a big problem.  But I'm not sure it would be an
> > improvement either.  Especially because I suspect it might give the
> > false impression that the code of ELisp packages is somewhat
> > security-conscious, whereas in my experience, the vast majority of Emacs
> > packages isn't (they may end up secure by accident, of course).
> >
> >
> 
> That is an extremely important point. Very few people even gives this a
> thought when installing packages - especially packages from MELPA and
> other external repositories. Having 'security' would imply for some that
> there is a formal security process for reviewing, tracking and reporting
> security issues. We don't have any of this and advertising some updates
> as security fixes could well create a false sense of security. 

Actually, in the context of Linux (the kernel), this question is
a longstanding discussion and regular fodder for flame wars.

While the core Linux developers (most prominently Linus Torvalds,
but also Greg Kroah-Hartmann) adamantly stick to the standpoint
that any issue is a potential security issue, so it doesn't make
much sense to arbitrarily flag some issues as security relevant.
Actually. they say, it is counterproductive.

There is, of course the opposite position (there are flame wars,
after all).

What the latter don't want to see is, that there actually are
three categories:

 (a) a proven security issue (there is a known exploit);
 (b) the grey zone (we don't know);
 (c) for sure not security relevant -- can you even prove
     such a thing?),

...and most of the issues are in (b). Besides, there won't be
a universal set of criteria everyone will agree upon.

It takes a significant amount of work to extract an issue out
of category (b) (aka "dunno") into either (a) or (c) I think
people advocating for such a flagging should somehow try to
dig up the resources for that. Regular developers are more
than busy fixing known issues, finding new ones, or not making
mistakes in the first place.

So the advocates of having this kind of flagging should be
the ones responsible for digging up new resources, IMO.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Stefan Monnier]

> So the advocates of having this kind of flagging should be
> the ones responsible for digging up new resources, IMO.

In the context of ELPA, I could suggest the following path:

- Step 1: improve the protocol so that `package.el` can display the
  "recent news" that (Non)GNU ELPA archives show in the HTML page (and
  the release announcements emails).

- Step 2: highlight keywords like "security fix" in the "recent news".

- Step 3: improve the "recent news" system so that `package.el` could
  distinguish the part of the news corresponding to the potential update
  (currently the recent news is not parsed so we don't know which news
  applies to which version).

- Step 4: highlight the updates that include "security fix" in their news.

I'm not sure "step 4" would be useful in the current context, but maybe
by the time we have made the previous steps (which are useful regardless
of step 4) the situation will be different.


        Stefan

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

We do not endorse or point to MEPLA, because it doesn't uphold our
principles of rejecting nonfree software.  So we don't get involved in
maintaining MELPA.  We have nothing to do with it.

When there is a package that happens to be in MELPA that we want to
recommend to users, we can put it in NonGNU ELPA.  There, we can give
it a little emergency maintenance if that seems called for.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Gulshan Singh]

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]

That makes sense. But I only brought up the MELPA example because I
recently encountered a security bug in a MELPA package. There's no reason
ELPA packages can't have similar security bugs (I just don't have an
example of this at the moment), and I figured it might be a good idea to
have some support for making it easier for users to quickly get security
updates for packages, regardless of what repository they're using.

On Sat, Aug 13, 2022, 8:23 PM Richard Stallman <rms@gnu.org> wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> We do not endorse or point to MEPLA, because it doesn't uphold our
> principles of rejecting nonfree software.  So we don't get involved in
> maintaining MELPA.  We have nothing to do with it.
>
> When there is a package that happens to be in MELPA that we want to
> recommend to users, we can put it in NonGNU ELPA.  There, we can give
> it a little emergency maintenance if that seems called for.
>
> --
> Dr Richard Stallman (https://stallman.org)
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>

[-- Attachment #2: Type: text/html, Size: 2009 bytes --]

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > There's no reason
  > ELPA packages can't have similar security bugs (I just don't have an
  > example of this at the moment), and I figured it might be a good idea to
  > have some support for making it easier for users to quickly get security
  > updates for packages, regardless of what repository they're using.

It makes sense for us to improve matters for GNU ELPA.
It's a desirable thing to do, and it's part of our work.

WHat remains is the practical question: what actions, that would
improve the situation, are feasible for us to do.  As I'm not an
expert on that, I will leave it to the others.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > That makes sense. But I only brought up the MELPA example because I
  > recently encountered a security bug in a MELPA package. There's no reason
  > ELPA packages can't have similar security bugs (I just don't have an
  > example of this at the moment), and I figured it might be a good idea to
  > have some support for making it easier for users to quickly get security
  > updates for packages, regardless of what repository they're using.

We can do that for the repositories that we support, whose packages we
can fix or whose maintainers have some relationship with us.  We have
no relationship with MELPA -- if you use that, you're on your own.

We do copy some packages from MELPA into NonGNU ELPA.  It takes a
little discussion, making sure the package does and will satisfy some
basic criteria.  But if the package is popular, we're glad to do that.
You can ask us to move the packages you use, if they are popular.

Do we support the NonGNU ELPA packages well enough now
for security updates?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Tim Cross]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > That makes sense. But I only brought up the MELPA example because I
>   > recently encountered a security bug in a MELPA package. There's no reason
>   > ELPA packages can't have similar security bugs (I just don't have an
>   > example of this at the moment), and I figured it might be a good idea to
>   > have some support for making it easier for users to quickly get security
>   > updates for packages, regardless of what repository they're using.
>
> We can do that for the repositories that we support, whose packages we
> can fix or whose maintainers have some relationship with us.  We have
> no relationship with MELPA -- if you use that, you're on your own.
>
> We do copy some packages from MELPA into NonGNU ELPA.  It takes a
> little discussion, making sure the package does and will satisfy some
> basic criteria.  But if the package is popular, we're glad to do that.
> You can ask us to move the packages you use, if they are popular.
>
> Do we support the NonGNU ELPA packages well enough now
> for security updates?

No and nor are the main elpa packages supported sufficiently enough to
implement a concept of security updates.

Once yhou distinguish updates such that you now include security updates
(in a similar manner to GNU Linux distributions like Debian, Fedora
etc), you create the expectation that

- there is some formal review and management of security issues. There
  isn't

- Packages are being reviewed and monitored for security issues. They
  are not.

- Updates not flagged as security updates do not have a security
  implication. This may not be true.

Essentially, all this will do is create a false sense of security. Users
will believe that provided they have applied all packages marked as
security updates that their system has no packages with known security
issues. As we don't have any formal tracking or management of security
issues and as we don't do any systematic or formal review of packages in
either GNU ELPA or non-GNU ELPA, we cannot provide and we should not
give the impression of providing any level of security assurance. In
fact, we should likely go completely the other direction and educate
users that when they add packages, especially non-GNU packages, it is
completely at their own risk.

The main reason there hasn't been a major security issue with Emacs and
the package system is down to good luck, not due to good security
policy. If Emacs was more popular and had a larger user base, making it
a richer target for those interested in compromising systems, we would
see similar problems to those experienced by NPM, Google and Apple
stores etc. All that is really protecting us now is that the rewards for
doing such are lower than the effort required to pull it off and we have
a few people who do informal scanning/reviewing of code (which is great,
but provides little formal assurance and is unlikely to pick up cleverly
crafted exploits which are designed to defeat such informal scans).  

What we could do which may provide some benefit to users is implement a
policy or practice which encourages package maintainers to label
security related changes in change logs or readme files in a specific
manner/format which makes them easy to spot. It is likely those who are
interested in security issues will check these files before applying
updates anyway. Those who just blindly apply updates are unlikely to
really be paying sufficient attention to security risks to benefit
anyway.