What is wrong with MELPA on Microsoft Github?

2020-10-19 This article will tell what is wrong with MELPA as repository of packages for GNU Emacs.

MELPA coerces both developers of GNU Emacs Lisp packages and free software users to use the proprietary Javascript on Microsoft Github.

Both developers and users who wish to file a bug report have no other option but to apply to MELPA by using non-free Javascript and becoming subjugated to Microsoft.

MELPA further allows inclusion any type of software even if such software is to guiding users to use proprietary software, or if such software was made to exclusively run or control proprietary software on users' computers or devices.

and it lacks basics of any security in software distribution, packages are unsigned, in fact, the continuous build system does not verify packages for security issues, it is an automated machine for distribution of software that lacks care for users.

MELPA DISTRIBUTING PACKAGES WRAPPING PROPRIETARY SOFTWARE

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

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

Jean

Leave Your Comment or Contact GNU.Support

Contact GNU.Support now. There is a simple rule at GNU.Support: if we can help you, we do, whenever and wherever necessary, and it's the way we've been doing business since 2002, and the only way we know