If information security people would spend the same amount of time they are spending complaining about this vulnerability trying to educate their organisations on the importance of supporting open source solutions they depend on we wouldn’t be in this situation.
I am sick of reading of very senior people complaining about the impact this vulnerability has had on their week when their companies don’t even contribute a penny to open source projects.
Maybe we should tell them to engage with open source, not "support it". Companies should look for a way to spend work hours on open source, not finding someone to send money.
Don't worry, legal will answer a completely different question that's unrelated, but rests on a fundamental misunderstanding of the entire premise due to a combination of misinterpreting technical jargon as plain English and then misapplying a legal generalization, resulting in absolutely essential advice that needs to be followed immediately, which is couched in legalese that the techs will proceed to misunderstand by misinterpreting legal jargon as plain English in combination with a misapplied technical generalization, resulting in an absolute quagmire when it turns out that these essential compliance steps turn out to have a minor impact on the next quarter's bottom line. Thus some even more obtuse interpretation will be dreamed up by some manager to claim CYA without hurting the bottom line (or addressing the reinterpretation of the reinterpretation of the reinterpretation of the original issue). The issue will be resolved, pending small details like the actual legal risk and technical issues, and all will be fine.
If it's an enterprise (https://zwischenzugs.com/2018/10/02/why-are-enterprises-so-s...) the latter will be a much easier sell to management. Paying for support is a given but contributing developer time will require many approvals from different departments if it can be done at all.
Just leads to the xkcd “there are now 14 competing standards.”
Honestly the biggest problem of package managers is finding a reputable package that one can trust.
The best one can do to aid this situation is reviewing, vetting and warning of which packages that can be trusted and not. Automatic scanners to find code smells and vulnerabilities.
“Security rating: 2/10, This package seems to use JNDI loading, are you sure you want to continue (y/n).”
Humor me: if log4j had 13 (independently developed) competitors, wouldn't the impact of this be much lower, because many consumers would use different libraries? Like genetic diversity as a hedge against disease.
I bet they'd all compete on features and probably implement the same exploit trying to maintain market share.
Logging as it's understood today should ship with most STD libraries. Things like logback an log4j really should just eventually be rolled into the std.
Not in and of itself.. However if part of that funding was used to cover formal (external) audits, investment in fuzzing/automated security testing etc.. then it might well have done
"Might have" is the operative word. In a world where Project Zero's _This shouldn't have happened_ [1] was also published this month (buffer overflow on NSS), I'm less certain. Quoted from the article:
----
This wasn’t a process failure, the vendor did everything right. Mozilla has a mature, world-class security team. They pioneered bug bounties, invest in memory safety, fuzzing and test coverage.
NSS was one of the very first projects included with oss-fuzz, it was officially supported since at least October 2014. Mozilla also fuzz NSS themselves with libFuzzer, and have contributed their own mutator collection and distilled coverage corpus. There is an extensive testsuite, and nightly ASAN builds.
I'm generally skeptical of static analysis, but this seems like a simple missing bounds check that should be easy to find. Coverity has been monitoring NSS since at least December 2008, and also appears to have failed to discover this.
Until 2015, Google Chrome used NSS, and maintained their own testsuite and fuzzing infrastructure independent of Mozilla. Today, Chrome platforms use BoringSSL, but the NSS port is still maintained.
Did Mozilla have good test coverage for the vulnerable areas? YES.
Did Mozilla/chrome/oss-fuzz have relevant inputs in their fuzz corpus? YES.
Is there a mutator capable of extending ASN1_ITEMs? YES.
Is this an intra-object overflow, or other form of corruption that ASAN would have difficulty detecting? NO, it's a textbook buffer overflow that ASAN can easily detect.
----
There's no way to argue that less than zero funding would have prevented the log4j maintainers from merging a patch that was sent to them by a third party.
I read a post recently that said part of the open source funding issue comes down to a financial "structure" mismatch. Open source folks are often individuals or loose collections of individuals. Sometimes they have things like Patreons, ask to receive crypto currencies, etc. Companies don't/can't provide funding via these types of structures, so the writer of the post ended up incorporating a company, setting up a mercantile bank account, commercial payment processing, etc., so companies would be comfortable funding his efforts. Fortunately, this path is lot easier lately with services like Stripe, etc.
That feels backwards. Little shops are flexible and can probably do what needs to be done. Lumbering behemoths have (too many) rules and restrict themselves (often) unnecessarily.
I am a developer in the midwest, and maybe if you hadn't completely missed my poin you wouldn't be such a jerk.
Nebraska is a reference to an XKCD Comic (https://xkcd.com/2347/). The idea is that there are nameless people all over the world contributing to critical open source infrastructure.
Back to the point.
Running Google Maps on one of my low traffic sites, would generate at most, several dollars a month in charges. It would be a rounding error in our budget, and we can't pay it. Our purchasing rules are not flexible enough to work with google.
Paying Google is hard enough, an independent oss developer with no company would be impossible. I would get laughed at if I suggested throwing a few bucks at a developers Patreon.
They must adapt. Period. And don't worry, when they have to, they do find solutions. The thing is, with open source, you don't have to, worse, the vast majority of enterprises rely because you don't need to make any effort.
> If information security people would spend the same amount of time they are spending complaining about this vulnerability trying to educate their organisations on the importance of supporting open source solutions they depend on we wouldn’t be in this situation.
Security teams are stuck with securing the tire fire; they didn't choose the library or platform. If anyone should be advocating for supporting open source, it's the developers who benefit by using open source libraries.
Saying things like "I don't like this software because <concrete reason>" is reasonable; it can be considered constructive criticism, especially if you include a way it could be done better. Heck, even just "I think it's too complicated to use, and the underlying code base needed to support that complexity lends itself to bugs that can be exploited" would be better.
Saying things like "No amount of money is going to impart good taste and best practices onto these projects" is insulting the people who wrote it with no real basis. It's not helpful and it makes you (and some other people in the thread) sound like a jerk.
The unfortunate thing about scratch rewrites is that they are not a good business. Open Source has conditioned people to think that libraries should be free. It's not clear to me that the alternative where libraries are obscenely expensive (like in the hardware world, where a hash table is a $100k investment) is any better. Nobody has ever built a successful company charging between $0 and $10,000 for a library. That is just how people see things, and unfortunately it is extremely hard to change.
Some platforms have reasonable markets for libraries; Advanced Messaging Systems[0], DevExpress[1] and Aspose[2] are three examples of companies that successfully sell software libraries for .NET, Java, and Office.
That wouldn’t be funding log4j2 though (from the ‘better authors’ part). That would most likely be an internal effort (devs you trust) published as a new open source logging framework in a sea of existing ones.
Honestly, absolutely not, and I think money would be harmful. Lots of software doesn't need a lot of work. It can be simple. When people get paid to solve problems there's an incentive to add more code, to add new domains, etc.
Use the standard java logger and move on, it's that easy.
Where’s my incentive to work the weekend supporting a project after a long week of supporting my production code? If we want solid and secure OSS, we gotta pay someone!
Presumably it's the same incentive that pushed you to write it the first time.
If you don't want to work on it anymore that's OK too. Open source libraries are generally not held to particularly stringent requirements by the vast majority of people - perhaps accepting an obvious patch in a critical situation, at most.
You obviously can pay people. They're called employees. The thing about employees is that your money translates to business value, which is much broader than a single library. This means that when a single library is done the developer doesn't have to think "ok but what's next for this library" and start adding more code. They can stop and move on to other tasks.
Paying for a single library is nice. I support multiple open source developers because I appreciate their work. I recommend everyone does so.
I don't at all believe it's going to help security though.
One of the maintainers in question holds two jobs to live. Having money might allow him more time to test and retest and update the software more expediently.
Sorry, I was posing that question semi-sarcastically. I agree it's blindingly obvious to any sensible person that money would help immensely. However, sadly, there are apparently plenty of people who are just about sensible enough to be able to get out of bed and navigate to this site, but not sensible enough to understand much else.
> educate their organisations on the importance of supporting open source solutions
Githubs of the world could just gate downloads, pull requests etc. behind a payment to see what is the real valuation of open source software; I imagine it'd mostly settle around $0 excluding couple of big projects.
Up until the semicolon, this was actually a decent point. I can see a future for high-quality open-source software hosted on an 'app store' which requires a small payment for use - or for commercial use, perhaps.
That's the question that such an effort would have to solve. I think you're assuming a model where software is directly used by an individual consumer, though, which is not always the case. For commercial applications where your software is integrated into the end product, for instance, companies would never risk stealing unlicensed code considering the risk. How one would address the question you posed is entirely dependent on the domain one's operating in.
