Over the weekend, Bleeping Computer reported on thousands of packages breaking because the developer of a package inserted infinite loops. He did this with intent. The developer had grown frustrated with his volunteer labor being used by large corporations with no compensation. This brings up at least three issues that I see.
FOSS sustainability
How many times have we had to relearn this lesson? A key package somewhere in the dependency chain relies entirely on volunteer or vastly-underfunded labor. The XKCD “Dependency” comic is only a year and a half old, but it represents a truth that we’ve known since at least the 2014 Heartbleed vulnerability. More recently, a series of log4j vulnerabilities made the holidays very unpleasant for folks tasked with remediation.
The log4j developers were volunteers, maintaining code that they didn’t particularly like but felt obligated to support. And they worked their butts off while receiving all manner of insults. That seemingly the entire world depended on their code was only known once it was a problem.
Many people are paid well to maintain software on behalf of their employer. But certainly not everyone. And companies are generally not investing the sustainability of the projects they rely on.
We depend on good behavior
The reason companies don’t invest in FOSS in proportion to the value they get from it is simple. They don’t have to. Open source licenses don’t (and can’t) require payment. And I don’t think they should. But companies have to see open source software as something to invest in for the long-term success of their own business. When they don’t, it harms the whole ecosystem.
I’ve seen a lot of “well you chose a license that let them do that, so it’s your fault.” Yes and no. Just because people can build wildly profitable companies while underinvesting in the software they use doesn’t mean they should. I’m certainly sympathetic to the developers position here. Even the small, mostly unknown software that I’ve developed sometimes invokes a “ugh, why am I doing this for free?” from me—and no one is making money off it!
But we also depend on maintainers behaving. When they get frustrated, we expect they won’t take their ball and go home as in the left-pad case or insert malicious code as in this case. While the anger is understandable, a lot of other people got hurt in the process.
Blindly pulling from package repos is a bad idea
Speaking of lessons we’ve learned over and over again, it turns out that blindly pulling the latest version of a package from a repo is not a great idea. You never know what’s going to break, even if it’s accidental. This still seems to be a common mode in some language ecosystems and it baffles me. With the increasing interest in software supply chains, I wonder if we’ll start seeing that as an area where large companies suddenly decide to start paying attention.
Ben, your thoughtful writing here raises a lot of questions–old and new–about how language ecosystems can help mitigate these sorts of problems. The problems are real, and the frustration that unpaid maintainers feel is, also. I am not sure there are any answers at all–and if there are, they wouldn’t be *easy* answers, certainly.
Something the Perl community has in the toolchain that at least raises *awareness* of these issues is the concept of a “River Stage.” The dependencies upon a package, both direct and indirect, are calculated and shown in a few spots on MetaCPAN. Consider Chad Granum’s modules, at https://metacpan.org/author/EXODIST; the blue bars to the left of the package name tell how dependent other modules are upon that package.
Tools like https://libyear.com can also help individual developers keep an eye on their dependency chains, as well, but there really isn’t a way, I don’t think, to do so on a more wholesale basis, in any way that would usefully prevent the sorts of incidents we’ve seen.
“We depend on good behavior,” you say in one of your headings up there–we do, and I think that as software communities, that may be our biggest mistake. As Robert Heinlein pointed out, “Never appeal to a man’s better nature. He may not have one.”
You’re right that there are no easy solutions. Just this morning, I saw a tweet pointing out that pinning to a specific dependency version (without regular checks for updates), is an invitation to exploit. That’s also true. How we strike the balance there is a problem that will produce many incomplete solutions for years to come. Maybe we’ll get there eventually.
You’re right, too, about the dependence on good behavior. The Heinlein quote is particularly apt. I may have a whole other post about that at some point in the near future.