Proposal to include obligatory PGP verification of packages from any repository

[Jean Louis]

This is related to MELPA subject and future Emacs repositories.

PROPRIETARY JAVASCRIPT ON MICROSOFT GITHUB ISSUE:
=================================================

I just guess that Github.com cannot be used with LibreJS, as I have
tried it, LibreJS report problems, this means all developers and
contributors to MELPA are automatically subjugated by Microsoft
Github, which is and was not the point of Emacs as free software part
of free operating system.

Additionally Github.com does not support many browsers, they publicly
say so, which in turn means that many users of free software browsers
from free software distributions are unable to access Github.com,
users of Github are supposed to use Firefox or Chrome or Microsoft
Browsers, while I am using Icecat and Iceweaseal-UXP from Hyperbola
GNU/Linux-libre -- so my experience with Github.com is narrowed, I
cannot access large parts of the website.

Developers using MELPA are misguided by Microsoft Github, and MELPA is
only following the popularity trend. Thus developers or old and new
contributors for reasons of getting included in MELPA are forced to
use non-free Javascript and browsers that are mostly not available on
free software distributions.

MELPA is telling users on its website that it is extensible, but
please "contribute your recipes via github, and we'll build the
packages", they are tageting Github, and thus lead Emacs users to use
non-free Javascript on Github. This is contradictory to purposes why
free software systems have been created.

There is https://savannah.nongnu.org then there is Trisquel hosting,
they would easily add Emacs packages without problem
https://devel.trisquel.info/users/sign_in then there are other
non-free Javascript and friendly free software hosting providers.

Could you maybe ask MELPA to switch to some free software hosting
sites for code, that way website would be accessible without using
proprietary Javascript.

That would be right direction to go for MELPA. 

It is good if we make incentive to those people who contribute to
MELPA to switch their hosting from Microsoft Github with proprietary
Javascript and their policies to some of free software hosting
providers, but what is really best is that MELPA switches to free
software hosting code providers.

AVOIDING EMACS PACKAGES WRAPPING PROPRIETARY SOFTWARE:
======================================================

This is other issue, it could be solved (as already somebody
mentioned) with one package to be developed in GNU ELPA, named similar
to "freedom-check" or even better as a built-in package that would
warn Emacs users about usage of non-free software or any other freedom
issues, it could ask user to disable those packages discovered on
system that are wrapping non-free software.

The package "freedom-check" would be for Emacs what is LibreJS on
browsers and what is "your-freedom" on Hyperbola GNU/Linux-libre and
other free software distributions.

It could disable or remove the packages that were installed to wrap
proprietary software. Additionally, it could disable repositories that
do not care about users' freedom and would tell users why is it so.

It would be good direction if such package is developed and then
beside being distributed on GNU ELPA, also injected in MELPA, as it
would be innovative package in users' interest, thus fully complying
with MELPA principles.

Let us not forget that inclusion of packages wrapping proprietary
software represents large security risk as well, not only that it
subjugates users or bring about a moral dillema.

OTHER SECURITY ISSUES ON MELPA:
===============================

For me largest security problem on MELPA is that Github.com is run by
Microsoft, we have no idea what principles they share beyond
commercial principles, and the more Emacs packages are hosted on
Microsoft Github, the more probability is there for mischievous
conduct or security breaches.

Same can be said for hosting providers that value free sofware,
security breaches are possible, but then we would know that people
maintaining the server do care of users enough, to prevent mischievous
conduct.

A package can be thus accepted in MELPA and become approved, then
later continuously updated, meaning without any control or
supervision, and then automatically offered to users. Backdoor can be
injected into users' Emacs and run on their computers. If I am wrong
on how MELPA works, you may tell me, that is what I understood from
their website.

SO FAR I KNOW there is no system of signing packages and verification
of such. I have verified MELPA git, and I cannot find that they are
using GnuPG or gpg or other system that packages were really made by
the author they claim to be made. This may be true at GNU ELPA too, I
did not verify it, but I know at that GNU ELPA is not automatically
built and offered to users blindly without verification (I at least
believe they are verified).

1. Github.com may not even know if somebody cracks some developer's
   account and changes few packages to misbehave, if they would be
   alerted, they would not maybe act in the best interest of the free
   software project, they would act in their own best interest.

2. MELPA managers do approve only GNU GPL or GPL compatible software
   to be included, they do not however continually verify or control
   the software, in fact they pull it by using recipes and build it
   automatically and offer automatically to users. Users in turn
   accept blindly packages, even though there is no mechanism to make
   sure that package was made by the author that was approved by
   MELPA. Let us say MELPA could maintain the list of public keys of
   authors, and then accept only packages that are signed by those
   same authors, before having them built, this would increase
   security this security issue, but not solve it, if packages are not
   verified by human.

3. Other issue is that users cannot trust MELPA only, as packages
   should be distributable from MELPA to other repositories, so each
   single package should be verifiable by user as well.

It is written in the Emacs manual: 41.4 Creating and Maintaining
Package Archives, that:

   Maintaining a public package archive entails a degree of
responsibility.  When Emacs users install packages from your archive,
those packages can cause Emacs to run arbitrary code with the
permissions of the installing user.  (This is true for Emacs code in
general, not just for packages.)  So you should ensure that your archive
is well-maintained and keep the hosting system secure.

   One way to increase the security of your packages is to “sign” them
using a cryptographic key.  If you have generated a private/public gpg
key pair, you can use gpg to sign the package like this:

     gpg -ba -o FILE.sig FILE

But it is not implemented into Emacs to verify packages being signed,
so my proposal is that Emacs get obligatory verification of a package
if such package is arriving from any repository and to warn user if
package was not signed. This would give initiative to MELPA to start
thinking about security issues.

That is one of reasons why Hyperbola GNU/Linux-libre and other
GNU/Linux distributions package some major Emacs packages, as that way
the package maintainers verify the package before it is included in
the free software distribution.

In the same manner Emacs should have a built-in package installation
procedure (that can be circumvented by users' configuration) to verify
all packages being installed by default.

Jean