This security vulnerability was reported in October (https://hackerone.com/reports/712065) and there have been 2 PRs open for 2 months that fix this issue, but lodash hasn't had any releases for a year. There is essentially one (unpaid) person who has power to release lodash, a library that a huge majority of reasonably-sized javascript projects now depend on.
How should the open source community address essentially abandoned projects that have become critical in the ecosystem?
Other than that: I find the microdependency / mass dependency trend in NPM very irritating. As a rule of thumb I think you should be able to know at least roughly all your dependencies + transitive dependencies and take some care that they're healthy projects. If you can't name them all - you probably have too many of them.
> The npm ecosystem needs something like the distinction between Ubuntu's "main" and "universe" repositories, so that you have a smaller subset of known-good packages with harmonized transitive dependencies, stronger centralized curation, a lot more direct scrutiny, tighter control over versioning, and some party that is responsible for addressing vulnerabilities and ensuring appropriate maintainership.
> Ruby Together is a grassroots initiative committed to supporting the critical Ruby infrastructure you rely on.
> Your financial backing allows Ruby Together to pay expert, professional developers to work on improving critical infrastructure projects.
> The Ruby Together board of directors, elected by members, selects the most impactful projects to fund.
> Ruby Together publishes monthly updates showing progress and our proven results.
It brings together companies and individuals concerned about stability and health of the ecosystem, provides a aggregated place to do high impact sponsorship of the ecosystem and the elected board then sets about making a detailed workplan and working out the best distribution of funds.
One dev on lodash? Discuss its importance; offer the dev funds to keep things up-to-date and if not them, have the resources to work out another way.
Check out their early reports to get a better idea of the initial refactoring work they did within the ecosystem.
The approach used by distributions is much, much better. Having a separate team of people responsible for packaging up software is a much better approach. This would allow the security patches to get in, help enforce a sane baseline of packaging standards, prevent the introduction of malware, and have someone accountable whose interests align more with downstream than upstream.
There is a docopt-ng package here: https://github.com/bazaar-projects/docopt-ng But users haven't found it yet. And sadly, there is no guarantee that the new maintainer won't also lose interest and abandon the project.
Definitely not an ideal situation. Yes, you can fork but how do you get visibility? How can the developer announce to the community that he or she wants to maintain the software?
I suspect if a human resource audit of open source were done, there would be surprisingly few people involved in the maintenance of these things.
Or work with a paid version of npm if you’re app is business critical.