Melpa: 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 (https://github.com/melpa/melpa/issues/5294, https://github.com/melpa/melpa/issues/3004, https://github.com/melpa/melpa/issues/1749, https://github.com/melpa/melpa/issues/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 https://github.com/melpa/melpa/issues/5294#issuecomment-400329362 could be a step forward.

[TxGVNN]

Hi everyone, I also have a question about this topic.

I always update packages every week, I wonder have ever the updated package has a new malicious code injected?
Suppose, I'm a maintainer of a popular package, one day I deliberately inject malicious code into source code. And mepla will automatically build it.

Does the Melpa repository have any mechanisms to prevent someone attempt to attack the user through emacs package from Melpa?

I ask this question because the last year we had an event about malicious code injected in a opensource.

• https://www.reddit.com/r/javascript/comments/a0n982/an_npm_package_with_2000000_weekly_downloads_had/
• https://github.com/dominictarr/event-stream/issues/116

Regards,

[milkypostman]

not sure there is any way mechanism to prevent anything like this. we're open to suggestions and contributions.

[purcell]

Does the Melpa repository have any mechanisms to prevent someone attempt to attack the user through emacs package from Melpa?

There's nothing to protect you against situations like the event-stream one. We stopped pulling source code from the Emacswiki, where anyone can edit code, but if a maintainer of a package hosted on github turns malicious or gives repo control to someone nefarious, then even github's security controls won't help.

The bottom line is that if you really care about security you need to audit every single new package version yourself: nobody else is doing this.

[TxGVNN]

Perhaps, everyone should check itself. I'm looking for a package to help everyone can check by themselves.
The package will show the difference between the updated and current package. I wonder do we have this package yet?

I always manually copy the old packages before executing the update. After that, I use diff command to check what changed.

[tarsius]

The package will show the difference between the updated and current package. I wonder do we have this package yet?

I though paradox supported that but didn't find it in the list of features just now.

Personally I use (and am the author of) borg a package where that doesn't treat reviewing changes as an afterthought--more like the main feature from which most other features derive. But it is very different from package.el, so this might not be for you.