Log4j Is One Big ‘I Told You So’ for Open Source Communities – InApps 2022

Another week, another bug that brings the internet to its knees, amirite?

As Steven J. Vaughan-Nichols wrote of the bug in the open source Java logging library Apache Log4j earlier this week, we are in so much trouble. The vulnerability, a zero-day attack called Log4Shell, is “as bad as it gets” he writes, noting its 10.0 CVSSv3 rating on a 0.1 to 10 scale, and allows attackers to “hit you with a Remote Code Execution (RCE) attack, which can be used to compromise your servers.” To make matters worse, another Log4j vulnerability showed up just after the first, though not as severe. Nonetheless, Vaughan-Nichols writes that the first vulnerability is so bad that it “is going to keep you up at night for weeks, possibly months, to come.”

None of this, by now, is new to you I expect, but the response to the news has been a pile-on moment for open source developers and maintainers, with many offering their own version of an “I told you so” alongside the perpetually pertinent xkcd comic that perfectly illustrates the issue at hand.

For example, one developer who goes by the name Xe, argues that “Open Source” is broken, writing that they “believe this is a perfect microcosm of all of the major ecosystem problems with ‘Open Source’ software.” The problem Xe points to is that often cited issue in open source — a complete lack of funding for maintainers of integral code. It takes just a few short paragraphs of this blog post before the above xkcd comic is embedded, with Xe offering Alpine Linux as another example of an open source project relied upon, yet likely not funded by those who use it.

“It is used frequently in Docker contexts to power many, many companies in production. How many of those companies do you think fund the Alpine Linux project? How many of those companies do you think would even THINK about funding the Alpine Linux project?” Xe writes.

Point taken.

PuTTY maintainer Andrew Ducker, meanwhile, offers his own take on the topic as someone who also maintains a piece of open source software relied upon by many, writing simply that “The internet (and many large companies) are dependent on software maintained by people in their spare time, for free. This may not be sustainable.”

Likewise, Go team member at Google Filippo Valsorda writes that, as someone who built a career on open source both at and outside big companies, this current scenario is a wake-up call for professional maintainers.

“Open Source software runs the Internet, and by extension the economy. This is an undisputed fact about reality in 2021. And yet, the role of Open Source maintainer has failed to mature from a hobby into a proper profession.

The catastrophic consequences are almost a daily occurrence,” Valsorda writes, before later concluding that “The status quo is unsustainable.”

The solution, argues Valsorda, is that, while “GitHub Sponsors and Patreon are a nice way to show gratitude,” they are “an extremely unserious compensation structure” and that we need to, instead, “professionalize” the role of the maintainer. That is, put them on the payroll.

“This is what I hope to see happen more and more: Open Source maintainers graduating to sophisticated counterparties who send invoices for ‘support and sponsorship’ on letterhead, and big companies developing procedures to assess, approve, and pay them as a matter of routine so that they can get what they need from the ecosystem. Eventually, a whole career path with an onramp for junior maintainers, including training, like a real profession.”

One final note on the entire affair — after the week you’ve just had dealing with the Log4j vulnerabilities, besides possibly a stiff drink or a vacation, you might also need a good laugh, and as such, someone has put together an entire website dedicated to Log4j memes that might do the trick.

This Week in Programming

• About That Whole Rust “Moderation Issue”: It’s been nearly a month now since the Rust moderation team, the group responsible for upholding the code of conduct and community standards within the Rust community, up and resigned without warning in protest of what it said was an “unaccountable” Core team. Now, Rust Library team lead Mara Bos has offered a follow-up on the moderation issue, which was recently sent to members of the Rust project as an email last week. In the follow-up, the core conflict still remains unsaid, as disclosing that would violate “the privacy of those involved, including of those who reported the issue.” Bos does, however, add a bit more context, writing that “over an eight-month period involving miscommunication and disagreements, this escalated into a trust issue between the moderation team and the core team,” which “ended up in an unworkable situation where no one could have the full context, making a path forward impossible.” To work on solving this issue, a new group was formed including “all top-level team leads, project directors to the Foundation, all core team members, and the new moderation team members, to discuss next steps.” Bos said that they will move forward with three high-level goals. First, they will work to fix “underspecified policies for handling complex moderation issues” with “publicly documented procedures.” Next, Bos writes that “the Rust project needs to adapt its structures for how it does governance.” And finally, they plan to “resolve the specific moderation issue that was at the center of the disagreement between core and the former moderation team” with details and plans “discussed publicly when we can ensure that doing so will not cause more confusion.”

• Generics Finally Drops in Go 1.18 Beta: That’s right, the long wait is finally over — generics are coming to Go 1.18 Beta 1. While it will be a few months until the official Go 1.18 release hits, this first preview release will, as they write, “let you kick the tires, take it for a spin, and let us know what problems you encounter.” This release is the first to include support for generic code using parameterized types, which they say are “the most significant change to Go since the release of Go 1, and certainly the largest single language change we’ve ever made.” To get started, check out the brief tutorial about how to get started with generics or the talk given at GopherCon last week. Of course, generics aren’t the only thing to hit with this release, so check out the blog post or the draft release notes for Go 1.18 for all the details. That said, we know generics is the thing really on your mind here, so we thought we might include a few other posts on the topic. First, Go developer Teiva Harsanyi wrote a blog post looking at when to use generics in Go, where he looks at “the concept of generics in Go and then delve into common use and misuses.” Harsanyi looks at several cases, examining specific code examples, before finally recommending not using generics “when it makes our code more complex,” and advising caution. “In general, when we want to answer when not to use generics, we can find similarities with when not to use interfaces. Indeed, generics introduce a form of abstraction, and we have to remember that unnecessary abstractions introduce complexity,” he writes. “Let’s not pollute our code with needless abstractions, and let’s focus on solving concrete problems for now.” Beyond the question of whether or not to use generics, Go developer Mark Phelps dives in head first and offers up his own experiences trying out generics in Go. Phelps set out to convert his “markphelps/optional library from using code generation to using generics instead” and documents the process, noting that he loves that he “was able to delete 95% of my code because of generics” and that he’s “not sure that most Go developers will be using generics daily, but it’s nice to know that they exist if we need them.”
• Python 3.6 EOL Is Here: One last headline of note this week, which Jack Wallen has already covered here at InApps but is worth linking to, is that it’s time to say goodbye to Python 3.6. “As of this month, Python 3.6 is dead to me,” he writes. “It should be dead to you as well.” The language version will no longer receive either bug or security fixes, and Wallen details the various ways you can deal with this, so head on over and see if you need to care — as with the Log4j vulnerabilities, the answer is “likely so.”

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.