Unless you’ve been disconnected from any digital or analog media in the past few days, you must have heard of the zero-day remote code execution (RCE) vulnerability detected in log4j, one of the most popular open source logging library for Java. Not running much or developing any Java application, the most interesting part about this whole fiasco, are the discussions sparked around it, especially with regards to maintaining open source projects.
As a lot of people have already written a lot of things on this topic, I’ll linking to existing articles, highlight some points, and add my own comments here and there.
The Origin?
Amidst all the news articles and blog posts, what seems to be kind of lacking, is a link back to the original report and discussions around proper/better vulnerability disclosure. Having a zero-day RCE in a widely used library is quite bad, but if everyone gets to learn about it before there’s a patch, things can turn quite ugly. Of course this is not to blame the reporter, but a “take home” lesson on the topic of security disclosure.
Some of the earliest “sources” I’ve found is this GitHub repository with a proof of concept (PoC) and the following tweet, which links a pull request from the 5th of December, which supposedly fixes the (part?) of the issue.
Open Source Maintenance
Having maintainers of an open source project scramble for a fix, then triggered responses like the following:
Which then lead to a series of blog posts from various people:
- log4j: between a rock and a hard place by David Crawshaw – HN discussion
- “Open Source” is Broken by Christine Dodrill – HN discussion
- “Open source” is not broken by Kailash Nadh – HN discussion
By what backwards compatibility means to me, a project like log4j will break fewer people by removing a feature like the JNDI URLs than by marking an old API method with some mechanical deprecation notice that causes a build process’s equivalent of
log4j: between a rock and a hard place by David Crawshaw-Wallto fail and moving it to a new name.
The author is advocating for backwards compatibility in their article, but how can you remove “features” and then claim to still be backwards compatible? I believe, one should rather stop hanging on to their major version number for decades and instead release breaking changes more regularly for the better (e.g. removing a questionable feature). If you abandon the system of a version number that indicates backwards compatibility and remove features between minor versions, you’re doing more harm, than a new major version release would do.
This is also my goal with SFML. We’ve been “stuck” on SFML 2.x for the past eight years. While it allowed for multiple books to be released, that are still relevant today, it also slowed down or outright prevented some innovation. Now that SFML 3 is finally in development, I hope we can iterate a bit faster, so new APIs can be crafted, and we hopefully see SFML 4 a lot sooner.
We should also be cautious about adding burdensome features.
log4j: between a rock and a hard place by David Crawshaw
For SFML I believe we’ve fended off a fair share of those features, but doing so comes at a cost. You offend people who were excited for the library, which in turn can lead to the spreading of (unwarranted) negative stigma. Personally, I believe the bigger issue with feature requests for SFML, is that those who make the request, quite often have little interest in actually implementing or even researching the required information for the feature to be implemented.
But I must admit that some efforts and work also hasn’t gotten the deserved attention, which I don’t like either and leads rather right into the other two articles.
I’ve had this kind of conversation with people before and I’ve gotten a surprising amount of resistance to the prospect of actually making sure that the random smattering of volunteers that LITERALLY MAKE THEIR COMPANY RUN are able to make rent. There is this culture of taking from open source without giving anything back.
“Open Source” is Broken by Christine Dodrill
As the response to this blog post covers most of my critique points as well, I just wanted to highlight this part, which really is a problem and a shame, that people’s volunteering work is not being properly appreciated, nor paid for, given that the users are companies with more than enough wealth to do so.
However, this perspective doesn’t take into account a) why people write open source software and b) the license agreements chosen for your projects.
FOSS, despite its legal manifestations, is still largely a system of spirit and goodwill. When someone makes a FOSS library available for $0, it is inevitable that a for-profit corporation whose sole purpose of existence by definition is to consume resources at $X and sell resources for more than $X for a profit, will consume it.
“Open source” is not broken by Kailash Nadh
I too believe, that most people writing open source software aren’t doing it, with the goal of making a profit. If you’re stance is that you want to be paid, for every line of code you write, then there are licenses that can enforce this, or companies, which would gladly hire and pay you to develop software for them. Releasing something in good faith with a FOSS license and being surprised or even angered when a company starts using it and demanding payment for it, is a bit contradicting. For example if your local groceries store puts up an ad, that you get some free item, if you go shop there this week and when you show up, they want you to pay for the supposedly free item, because they suddenly have gotten a lot of interest and customers, you probably could legally require them, to give you the item for free. So how come, when we developer publish something and advertise it as free, we get upset when companies make use of that free offer?
As SFML is zlib licensed we rarely get to hear, when companies use SFML, but every time we do get a glimpse at a product running with SFML, it makes me quite happy. I’ve also personally helped out someone, getting SFML to work on macOS with a special setup they use for a commercial product and didn’t ask any money for it, but this was my choice to make. Just because I’m a maintainer of SFML, with lots of knowledge about and around the library, I never feel obligated to run after issues, that someone opens or asks help for. Of course I’m very interested in getting it fixed regardless, however the motivation doesn’t come from a company/user demanding a fix, but from my own interest in maintaining a great open source library. Neither would I cancel my vacation or day trip just to fix some “urgent” issue. This is really a question of priority and if open source projects, that you’re not being paid for, take priority over your personal relationships with friends and family, you may want to reconsider…
In Conclusion
Make sure you’re aware, that publishing code for free, doesn’t entitle you to being paid, even if the code gets used by mega-corps. If you want to get paid for writing open source code, ensure you pick a license or dual-license model that allows for this. It’s always a good idea to bring up the topic of open source software donations to your boss/CFO/etc. whenever you get the chance. What open source software without mega-corp backing are you using on a daily basis and when have you last donated some money or time to them?
One thought on “Discussions Around log4j and FOSS”