Following up on the discussion on Elixir Slack.
It would be really cool if hex.pm would provide a feature like the “Report A Vulnerability” process on NPM.
There would have to be a small team of trusted people reviewing those reports and taking actions based on that report.
I haven’t put much thought into that yet since the idea just came up.
Sounds like a good idea 
Slightly related, there was some talk about expanding Hex.pm a couple of years ago - the thread contains some ideas about incorporating GH stars and other ideas to gauge popularity etc.
Perhaps some of those ideas could be considered at the same time?
I don’t see what those features have in common.
They could help people ascertain whether they might want to use the package or not (based on popularity/user recommendations, whether there are any unfixed vulnerabilities etc).
whether there are any unfixed vulnerabilities
GitHub stars are a really bad metric for that. Package Versions with a vulnerability should be retired to show that they are not secure.
For reference, this is how npm handles their process:
I really like the process and would like to adapt that to hex with small changes.
Since we have a great retirement feature, we should also retire the affected version as soon as the security advisory is released.
A GPG Key for the security report email address should be published.
The biggest questions is in my opinion how we put together a team to do that job.
I see it working like npm’s vulnerability report feature [1]. We have a form on hex.pm where vulnerabilities can be reported, when a new report is submitted it will be reviewed and if it is determined that there may be a security issue we will notify the package owners. The report will be disclosed publicly after a fix has been released or after certain of days regardless if there is a fix.
It can be integrated with mix hex.audit and package versions with publicly disclosed vulnerabilities should have it visible on their package page.
The reviewers would be a group of volunteers that are trusted in the community and have a track record of working on security issues.
Implementation wise for Hex it is not a lot of work, the bigger problem is putting together and organizing the group reviewers.
To keep the scope small I suggest we focus on the vulnerability reporting instead of including other features such as GitHub integration.
What if the vulnerability is an edge case or considered minor for some? For example, a vulnerability that only exists when using a certain OS? There could, for instance, be an issue when using a package on say a Windows machine, but it wouldn’t impact all those who deploy to a Linux box.
Then it’s imho still better to run the patched version besides the fact that I cannot see a way to relyably detect where someone is deploying to.
The retiring of a version does not prohibit users from using it. It shows them that there is a problem and has a text explaining the problem. Therefore users that are not affected can either do nothing or still update to a hopefully existing patched version.
Ah right sorry. I thought it meant they would no longer be useable when running mix deps.get.
If this idea ends up picking up traction and you do look for a team of reviewers, I’m happy to help out with defining that process and jumping onboard.
I’ve been working in security professionally for a long time, and coding Elixir professionally for a few years, and I wouldn’t mind something like this coming to the Elixir ecosystem.
© Copyright Elixir Forum | Terms | Privacy & Cookies
