Security in the emacs package ecosystem

Security in the emacs package ecosystem

[Husain Alshehhi]

Hello,

This issue is not new and seems to have been discussed before:
  <https://emacs-devel.gnu.narkive.com/atiq1AoP/security-of-the-emacs-package-system-elpa-melpa-and-marmalade>

I was wondering if things have changed since then.

To summarize: most users in emacs downloads packages directly from the git repository. This is a security threat as there is nothing to prevent a malicious change from going to users. The malicious change could be posted through a hack, or could be posted by the owner of the package (in extreme cases). Is there anything currently in the ecosystem, or package repository, to prevent these sorts of issues? Are there any initiatives or ideas to address these issues? If not, what is the recommended (and practical) ways to be safe?

(Some solutions that are typically thrown out: manual code review of every package installed. Use distro package manager and have emacs packages go through the normal package review process of each distro. Package signing. melpa/elpa stamp of approval.)

Husain

Re: Security in the emacs package ecosystem

[Ihor Radchenko]

Husain Alshehhi <husain@alshehhi.io> writes:

> This issue is not new and seems to have been discussed before:
>   <https://emacs-devel.gnu.narkive.com/atiq1AoP/security-of-the-emacs-package-system-elpa-melpa-and-marmalade>
>
> I was wondering if things have changed since then.

To followup, how are the plans (stated in the referenced discussion)
about signing ELPA packages?

AFAIK, ELPA currently re-builds package tarballs every time a new tag
appears in the source repo. No signature checks, nothing to prevent
potential breach in the source repo.

And ELPA tarballs themselves are not signed. Same for non-GNU ELPA,
AFAIK.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Security in the emacs package ecosystem

[Stefan Kangas]

Ihor Radchenko <yantar92@posteo.net> writes:

> To followup, how are the plans (stated in the referenced discussion)
> about signing ELPA packages?
>
> AFAIK, ELPA currently re-builds package tarballs every time a new tag
> appears in the source repo. No signature checks, nothing to prevent
> potential breach in the source repo.

I think we should add some flag to the build system saying that a
package should only be released if the new tag has a valid signature.
This would have to be optional for now.  (It is of course already best
practice to always sign your tags regardless.)

IMO, opening a feature request for this in the bug tracker would be
useful.  A patch would be even better.

> And ELPA tarballs themselves are not signed. Same for non-GNU ELPA,
> AFAIK.

GNU ELPA and NonGNU ELPA does sign packages, see for example:

    https://elpa.gnu.org/packages/company-0.9.13.tar
    https://elpa.gnu.org/packages/company-0.9.13.tar.sig

For some reason, the signature file is not linked from the web
interface.  I think we should add such a link.

If I'm not mistaken, MELPA unfortunately does not sign packages.

Re: Security in the emacs package ecosystem

[Ihor Radchenko]

Stefan Kangas <stefankangas@gmail.com> writes:

> I think we should add some flag to the build system saying that a
> package should only be released if the new tag has a valid signature.
> This would have to be optional for now.  (It is of course already best
> practice to always sign your tags regardless.)

This is a good measure and will certainly improve security.

Another consideration is that package recipes can be directly edited by
anyone. If an account of a person with write access to, for example,
ELPA is compromised, ELPA recipes can be arbitrarily manipulated for all
ELPA packages. This includes re-targeting the source repo or simply
disabling the signature verification.

I am raising this because a breach of a package repo means a significant
probability of leaked ssh keys. The same ssh keys can be used to access
ELPA then.

> GNU ELPA and NonGNU ELPA does sign packages, see for example:
>
>     https://elpa.gnu.org/packages/company-0.9.13.tar
>     https://elpa.gnu.org/packages/company-0.9.13.tar.sig
>
> For some reason, the signature file is not linked from the web
> interface.  I think we should add such a link.

I opened a bug report to create an actionable item on this.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61569

> If I'm not mistaken, MELPA unfortunately does not sign packages.

Looking at 43.4 Creating and Maintaining Package Archives, signing is
actually recommended. WRT MELPA we can do the following:
1. Open an issue
2. Allow users to demand package.el to verify signatures when
   downloading packages. Interested users can then increase their
   security by rejecting packages without .sig file.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Security in the emacs package ecosystem

[Ihor Radchenko]

Ihor Radchenko <yantar92@posteo.net> writes:

> 2. Allow users to demand package.el to verify signatures when
>    downloading packages. Interested users can then increase their
>    security by rejecting packages without .sig file.

Ok. And it is indeed already in place.
`package-check-signature' customization.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Security in the emacs package ecosystem

[Stefan Kangas]

Ihor Radchenko <yantar92@posteo.net> writes:

> WRT MELPA we can do the following:
> 1. Open an issue

I had a look, and turns out that there is one already:

    https://github.com/melpa/melpa/issues/1749

> 2. Allow users to demand package.el to verify signatures when
>    downloading packages. Interested users can then increase their
>    security by rejecting packages without .sig file.

Maybe I'm missing something, but isn't that `package-check-signature'?

Its current default is `allow-unsigned', however, which is about as
useful for security purposes as if it was nil.  I think we should
consider changing it to t in Emacs 30.

Re: Security in the emacs package ecosystem

[Ihor Radchenko]

Stefan Kangas <stefankangas@gmail.com> writes:

>> 2. Allow users to demand package.el to verify signatures when
>>    downloading packages. Interested users can then increase their
>>    security by rejecting packages without .sig file.
>
> Maybe I'm missing something, but isn't that `package-check-signature'?

It is. I found it shortly after sending my message.

> Its current default is `allow-unsigned', however, which is about as
> useful for security purposes as if it was nil.  I think we should
> consider changing it to t in Emacs 30.

If the default is t, users will be forced to have OpenPGP installed.
Maybe the default should be like t, but only when OpenPGP is available.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Security in the emacs package ecosystem

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Husain Alshehhi <husain@alshehhi.io>, emacs-devel@gnu.org
> Date: Sat, 18 Feb 2023 10:57:34 +0000
> 
> Stefan Kangas <stefankangas@gmail.com> writes:
> 
> > Its current default is `allow-unsigned', however, which is about as
> > useful for security purposes as if it was nil.  I think we should
> > consider changing it to t in Emacs 30.
> 
> If the default is t, users will be forced to have OpenPGP installed.

Right.

> Maybe the default should be like t, but only when OpenPGP is available.

We could also display a warning, once, when we detect that OpenPGP is
not available and set the value to allow-unsigned.  This way the user
is alerted to the problem and can take action to fix it.

Re: Security in the emacs package ecosystem

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

  > > Maybe the default should be like t, but only when OpenPGP is available.

  > We could also display a warning, once, when we detect that OpenPGP is
  > not available and set the value to allow-unsigned.  This way the user
  > is alerted to the problem and can take action to fix it.

Alternatively, we could use Autoconf to check for GPG or PGP
when building Emacs.

-- 
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: Security in the emacs package ecosystem

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> Alternatively, we could use Autoconf to check for GPG or PGP
> when building Emacs.

That will not work if GPG or PGP is installed after building Emacs.

Re: Security in the emacs package ecosystem

[chad]

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

On Mon, Feb 20, 2023 at 12:19 AM Richard Stallman <rms@gnu.org> wrote:

> Alternatively, we could use Autoconf to check for GPG or PGP
> when building Emacs.
>

Practically speaking, I expect this concern to apply mostly when users
install but don't build their own emacs, plus it is likely to misfire when
distributors build emacs.

Separately, if we think this is important enough to *want* GPG/PGP/etc more
often, we could ask the distros to add it as an optional dependency.

Hope that helps,
~Chad

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

Re: Security in the emacs package ecosystem

[Thomas Koch]

I believe, the question of the original poster has not been addressed. It was about Emacs packages, not about Emacs itself.

The Emacs manual only mentions, that package archives can be signed and that "Package archives should provide instructions on how you can obtain their public key." (emacs, 48.3 Package Installation)

There are no such instructions on https://elpa.gnu.org nor is there any information on security.

(Somewhat rude question: Is Gnu Emacs trusting the security of its users to Microsofts GitHub?)

Related:

- https://www.reddit.com/r/emacs/comments/63e8hu/are_emacs_package_repositories_a_security_risk/
- 2013 thread: "security of the emacs package system, elpa, melpa and marmalade"
  https://lists.gnu.org/archive/html/emacs-devel/2013-09/msg00450.html
- https://theupdateframework.io should be helpful for anybody working on software update systems

Re: Security in the emacs package ecosystem

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

  > The Emacs manual only mentions, that package archives can be
  > signed and that "Package archives should provide instructions on
  > how you can obtain their public key." (emacs, 48.3 Package
  > Installation)

  > There are no such instructions on https://elpa.gnu.org nor is
  > there any information on security.

We need to provide information about these topics, as well as
everything else we expect ELPA package maintainers to do, and
whatever we want them to agree to.

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

bug#66369: Change package-check-signature default to t

[Stefan Kangas]

Severity: wishlist

I propose to change the default of `package-check-signature' to t when
gpg is available.

Previous discussion here:

    https://lists.gnu.org/r/emacs-devel/2023-02/msg00680.html

The current default is `allow-unsigned', which is about as useful for
security purposes as if it was nil.  But if the default is t, users will
be forced to have OpenPGP installed.

In the above discussion, Eli suggested:

> We could also display a warning, once, when we detect that OpenPGP is
> not available and set the value to allow-unsigned.  This way the user
> is alerted to the problem and can take action to fix it.

I'd add that we could also prompt in this situation, perhaps something
along the lines of:

    "No working PGP installation detected; install package(s) without
    verifying signature (unsafe)? (y/n)"

Making `package-check-signature' more restrictive by default

[Stefan Kangas]

Ihor Radchenko <yantar92@posteo.net> writes:

> If the default is t, users will be forced to have OpenPGP installed.
> Maybe the default should be like t, but only when OpenPGP is available.

Right.  And if we want to make a change like this, I think we should
make sure to coordinate with the MELPA folks as well.  It would be
unfortunate if the first thing MELPA users did was to turn this off.

Once that is done, perhaps something like this could work?

diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index a0bb5e75393..763f0dcadd0 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -345,7 +345,7 @@ package-gnupghome-dir
   :risky t
   :version "26.1")

-(defcustom package-check-signature 'allow-unsigned
+(defcustom package-check-signature (and (epg-find-configuration 'OpenPGP) t)
   "Non-nil means to check package signatures when installing.

 This also applies to the \"archive-contents\" file that lists the