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] Create Hex.pm Vulnerability Disclosure Feature
[2] https://github.com/hexpm/hex/issues/632
[3] https://github.com/hexpm/hexpm/issues/753
[4] https://github.com/hexpm/hexpm/issues/754
