I think it’s impossible to avoid this situation completely in an open ecosystem without curated packages.

What we can work on is to avoid the chances of it happening and when it happens reduce the scope of it and how quickly we can mitigate it.

First of all I think there’s less of a chance this happens in the Elixir ecosystem compared to the NPM ecosystem. I have very rarely seen Elixir projects with more than a hundred dependencies, but it’s not uncommon for Javascript projects to have thousands of dependencies. Because of this there is less of a chance of an unwanted dependency sneaking in.

But having few dependencies is not a strategy. It’s important for the package manager to have a policy on how to handle vulnerabilities in packages. Currently Hex does not have a clear policy but we have been discussing it and we created a proposal a while back on a process on how to disclose and handle package vulnerabilities [1].

One way to reduce the chance of being affected by this is to review the dependencies you are using. This can be tough and reviewing the full source code of every dependency you are using may be unfeasible. @wojtekmach proposed a new task for diffing the changes between two package versions [2] which can be useful when updating dependencies. We also opened an issue to display the publisher of a given package version [3]. We also want to make the audit log for packages public so that you can get full insight of all the changes to a package, including added or removed package owners [4].

EDIT: Please read through the proposals and issues and give your feedback. They are great starter issues if you want to start contributing to Hex.

[1] https://forum.elixirforum.com/t/create-hex-pm-vulnerability-disclosure-feature/15905/7
[2] Add `mix hex.package` task · Issue #632 · hexpm/hex · GitHub
[3] Store and display publisher of package version · Issue #753 · hexpm/hexpm · GitHub
[4] Make audit log public · Issue #754 · hexpm/hexpm · GitHub

I don’t believe that’s the case. NPM has hooks that run when you install a dependency, which was actually used to create a worm [1] that spread to package publisher’s machines. In Elixir no user code is executed when you fetch a Hex package (not the case for git dependencies), only when the dependency is compiled is user code executed.

After the worm vulnerability was published Hex created extra mitigations for worm-like attacks by encrypting your local API key by default which prevents a worm from spreading without a user inputing their password.

[1] NPM Worm Vulnerability Disclosed - InfoQ

I think that with free software, you get what you pay for. It’s your responsibility to review the dependencies you use. Fortunately, reviewing Elixir code is very easy, because the language is not as weird as Javascript.

However, it might be an interesting exercise to jude malicious code in an elixir project… I’d like to propose a contest in this vein: http://www.underhanded-c.org

The Underhanded C conest is a context in which the goal is to creaft a piece of malicious C code that passes visual inspection.

Most of the tricks they use don’t work in Elixir, but I’m sure there might be some interesting things one can discover in a context like this.