Security issues raised by building packages from non-centralized sources

[alphapapa]

With the news of the GitHub acquisition by Microsoft, many repos are moving to other hosts. Some are choosing GitLab or other relatively popular "forges," but some are moving to what appear to be self-hosted or "one-off" forges.

While building from GitHub-hosted repos was never necessarily secure (since GitHub's authentication is a single point of failure), being the major platform that it is, they obviously have resources and staff dedicated to security. This surely raises the bar, to some extent, for an attacker to compromise a repo that MELPA builds packages from.

I don't think we can reasonably expect the same to be true for smaller and self-hosted forges and repos. Without trained, full-time staff maintaining and monitoring such systems, they are likely to be vulnerable to compromise due to outdated software, poor configuration, etc.

Of course, AFAIK MELPA has had the ability for a long time to build packages from simple HTTP URLs that point to git repos, so this is not a new issue. (And, of course, it built from EmacsWiki for years, as well.)

But consider, if you were an attacker, and you wanted to compromise systems used by Emacs users (of which, likely, a higher than average proportion are themselves maintainers of widely used software, and present a valuable target), how hard would it be to find a package that is:

• Hosted on a small or self-hosted server
• Is infrequently updated
• Has hundreds or thousands of downloads

...and then use commonly available tools to find vulnerabilities in the server, break in, compromise the package (add code to automatically install a rootkit or user-level trojan, etc), then wait for MELPA to build the package and users to install it and become compromised. And being infrequently updated (and the author's apparent activity and attention could also be evaluated by the attacker), and the fact that most users upgrade packages en masse without comparing changes, how long would it take for such a compromise to be noticed? (A clever attacker could even monitor the downloads and restore the repo after a time to try to hide his tracks.)

I'm by no means an expert, but I think this wouldn't be that hard for a motivated, knowledgeable attacker.

I'm not sure how much MELPA could mitigate this (the only thing approximating a solution essentially being to only build from signed and verified git tags). Of course, this discussion has essentially been had on other issues (#5294, #3004, #1749, #2342, etc), so perhaps this should be closed as a duplicate.

However, I think the GitHub "diaspora" presents this issue in a slightly different light, and perhaps reemphasizes the urgency of dealing with this problem, to the extent it can be.

@milkypostman @purcell @tarsius @DamienCassou

[DamienCassou]

The approach described #5294 (comment) could be a step forward.

[DamienCassou]

The approach described #5294 (comment) could be a step forward.