Re: Proposal to include obligatory PGP verification of packages from any repository

[Vasilij Schneidermann]

As someone working in information security, I feel compelled to reply to
this in detail as your email contains several claims I am not
comfortable with being taken at face value.

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

There is a difference between trying (enabling LibreJS and looking at
how many scripts it blocked) and trying (enabling LibreJS and actually
using the website while paying attention to how functional it is).  Out
of curiosity I've attempted the latter as it's a more meaningful test,
using the latest version of Firefox Developer Edition on Arch:

- Repositories can be created
- Issues can be created
- Forks can be created
- Pull requests can be created, with the limitation that the merge
  preview is broken.  This doesn't matter though as it's up to MELPA
  maintainers to review the pull request.
- Account creation is broken.  I can fill out the first screen
  (username, email address, password), then get stuck on the second
  screen as it relies on an external CAPTCHA service.  I suspect I can
  complete the process by temporarily allowing the JS script and
  continue contributing to repositories, but haven't verified that
  part.

My verdict so far: Github almost passes the test.  If one does have an
account already (from what I've seen you do), there is no excuse for you
to not contribute.  If one doesn't, they'll have to ponder whether
whitelisting the CAPTCHA is worth it.

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

From a security perspective it's a bad idea to use any browser outside
of the main stream as only the largest browser vendors manage keeping up
to speed with security issues.  While one can use a browser based on
them, there will be issues.  As a side point, Debian settled its
trademark dispute with Mozilla and no longer offers rebranded versions
of Firefox.  Therefore Debian users will not face browser
incompatibility problems and avoid such security issues.

Something else worth trying is hub [1].  It seems to allow performing
the expected contribution workflow from the command line.

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

This is a regrettable aspect of MELPA (although I disagree with non-free
JavaScript or security being a problem), I don't have expectations for
it to change as MELPA's philosophy revolves around the central principle
of going with the most convenient mode of operation for developers to
publish their packages:

- Use Github, the most popular gratis Git hosting service
- Use Github's contribution workflow (forking and "pull requests")
- Automatically fetch packages from developers (as opposed to having
  them submit/upload new versions)
- Automatically rebuild packages after each detected commit
- Remove support for unpopular alternative workflows to reduce
  maintenance effort (Emacswiki, Bazaar, CVS, Darcs, Fossil, Subversion)

One does not share a package on MELPA to further the goals of the free
software movement, one does so to reach as many Emacs users as possible
with relatively little effort (which excludes GNU ELPA, we'll have to
see whether the same holds true for non-GNU ELPA).

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

Savannah does not strike me as an adequate alternative for people used
to Github.  For starters it requires approval of each project before
it's publicly visible.  I'll have to do a proper evaluation of it though
before I can comment further on this aspect.  Gitlab is the closest
equivalent, though not perfect either.  For minimalism and integration
of an email-centric workflow sourcehut looks ideal, once it leaves its
alpha status.

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

As elaborated above, it is unlikely to happen.  Adherence to GNU
principles for non-GNU projects is not a priority.  See also the MELPA
maintainers' response to a thread you've created [2].

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

This is an interesting idea, though it will require continuous updates
for best effect.  Even if it doesn't prove to be effective in practice,
having a detailed list of what exactly is a problem to one's freedoms
would be a useful side effect for users caring about this.

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

This argument does not follow.  A code forge can have security issues,
no matter whether its code can be freely audited or the political
alignment of its owners.  Merely being concerned about free software
doesn't mean that security issues will be investigated and acted upon,
neither does ownership by an entity pursuing different goals mean it
will neglect security issues.

I've briefly looked into Savannah's source code and found enough
evidence of it not being securely designed and requiring an in-depth
source code review.  While talking to a security-related contact person
I've been told that there was indeed a little-known security breach long
time ago.  Linus' law [3] seems a more appropriate hypothesis to explain
this behavior, depending on the visibility and amount of people actively
looking into a code forge, there will be more publicized security
incidents and attempts to improve overall security of the project.
Freedom and political alignment of the project are at best tangentially
related.

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

That is indeed correct, there is no further quality assurance after the
initial submission.  It takes a significant amount of time for that
submission to be verified due to the few reviewers and given the sheer
amount of packages (4750 packages at the time of writing), I do not see
this working out with their current team.  For comparison, Arch has
"Trusted Users" responsible for their official packages, with anywhere
between 5 and 90 packages assigned to each of them.  Rest assured that
they don't perform security audits, only basic quality assurance as
packages are updated and bugs trickle in.  Having the kind of work force
a GNU/Linux distribution has is a luxury, not something to take for
granted.

That aside, how does this quality assurance look like for GNU ELPA?  Is
it users subscribing to a commit mailing list and looking out for
anything suspect?  Fewer releases overall?  A basic level of vetting by
asking for copyright assignment?  I doubt that code is audited for every
release either and that security issues are instead dealt with in a
reactive instead of proactive manner (meaning, as soon as one is known
of, appropriate measures such as a security release are taken).  There
is a lot more work to be done here, such as defining a comprehensive
threat model to work with.  Another important aspect: Say that non-GNU
ELPA manages to catch up with MELPA in terms of package count, does the
existing review system still work?  Will new measures be necessary to
guarantee security (for example by designing packages in terms of a more
restrictive approach with permissions, sandboxing and whatnot)?  I
strongly suspect that they will be and merely mirroring MELPA packages
won't suffice.

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

As mentioned above, MELPA's principle of going with the most convenient
option makes this a non-starter.  Vetting package authors for their
identity, requiring a GPG key and signed releases is something I'd
rather expect for GNU ELPA than them.

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

Github offers 2FA to protect accounts and has a dedicated security team
reacting to incidents.  I don't see signs of either for Savannah.  The
only point in favor of Savannah is it being relatively unknown and
therefore of less interest to attackers, but I wouldn't rely on that as
my only level of defense.

That aside, it's not even necessary to hack an account to distribute
malicious software.  Popular package archives for other programming
languages have seen attacks such as typo squatting [4]creating
(uploading a package with a misleading name) and hostile maintainers [5]
(where a package is transfered to a new maintainer who then abuses the
trust created by the package by adding malicious code to it).  I have to
confess I've pondered creating a malicious package for demonstrating how
easy it would be to sneak something in without anyone noticing, but I'm
afraid it will only lead to more emails sowing Fear, Uncertainty and
Doubt.  Or people weaponizing the code, not sure is likelier.

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

For this to be effective, one needs to build upon trust.  I doubt the
average Emacs user has thought in depth what package developers to trust
and whether they should verify packages installed to come from them.
And again, with MELPA's philosophy being one of convenience, I don't see
that happening.

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

Emacs does have basic verification already, but it is far from ideal.
The failure case is not handled well at all, users are not told what to
do when it fails verifying a package and are inclined to instead disable
the mechanism once and for all.  If an Emacs is too old to contain the
appropriate GPG keys, the keyring will be needed to be updated outside
of Emacs, a task that can fail for opaque reasons due to key servers
being unreachable.  There is initial work in form of the
gnu-elpa-keyring-update package distributed via GNU ELPA, but it suffers
from a bootstrapping problem and needs to be installed *before* the keys
become outdated.  Until this issue is solved, I cannot imagine making
this opt-out or even mandatory.  For comparison, Arch ships its own
package manager specific GPG keyring and updates it during each package
update operation.

[1]: https://github.com/github/hub
[2]: https://github.com/melpa/melpa/issues/7185
[3]: "Given enough eyeballs, all bugs are shallow."
[4]: https://incolumitas.com/2016/06/08/typosquatting-package-managers/
[5]: https://snyk.io/blog/a-post-mortem-of-the-malicious-event-stream-backdoor/

signature.asc
Description: PGP signature