Maybe there is nothing wrong with the "status quo", maybe we don't need yet another attempt to finance small FOSS projects where it's hard to explain how money will actually solve any of these issues.
Maybe people just need to be more considerate of what they depend upon. And in the case that a popular yet well maintained project has a CVE on day, maybe we need to accept that popularity does not make them invulnerable to bugs, all software has bugs.
Quite honestly, I think that if companies paid open source maintainers to get the features they wanted, the log4j problem would NOT have been averted at all, it would likely have happened earlier... notice that the source of the issue (support for JNDI lookups right into any log messages) was introduced because of someone asking for that feature (and getting it for free!)... if a company had paid for it, it would've been just the same, I doubt very much the company would have done any kind of security veto on the implementation.
What's needed is for open source libraries to somehow get "rated" by security experts before they get used by businesses. If those businesses using it paid for that, and then paid someone to fix any issues found, then I think we would have a working solution. Just paying for features would just make things worse... have you ever seen companies paying for security features, though?? No, I haven't at least... they pay for business features that will make them money, they hope, security is kind of just implied (and they might lay the blame entirely on the developer if they actually had a business relationship with them - which may be a big nightmare, actually, for OSS developers - and I am one of them myself... you can no longer use a license that just says you're not liable to anything bad that happens).
Perhaps OSS has become too sophisticated and professional-standard for its own good, while still being created and maintained by amateurs.
I have an analytics package which is apparently being evaluated by the military of a large country. Even if secure code, now the maintainers themselves are under attack.
For I am definitely a weaker link than a soldier or agent or gov department. Did not expect such usage when creating this project. If said government had seen how this was developed and tested, they would probably physically destroy the machines it is installed on.
Most every company I've worked for, large and small, has paid for professional third party security audits that scrutinize the dependency chain. log4j still wasn't flagged as problematic.
That's more an argument against old-school "no amount of architecture is ever enough" Java -- not so much an argument against the principle that engineer-time can fix bugs.
This bug was not consequence of not enough developers. And there will never be guaranteed "no security issue" situation. That level of certainly is simply too expensive.
I don't really see how the Log4J2 issue would have been uncovered by testing. It's not really a bug but more of a design flaw.
The reason is that the whole JNDI string interpolation feature by itself opens a door to a whole world of layered complexity which you can't comprehend. And even if you could comprehend it all Java could add some feature to JNDI which introduces an issue which wasn't there when it was all tested.
Anyone who knows anything about JNDI would've immediately recognized that this was an incredibly bad idea, as JNDI attacks are well known around black-hat circles (LDAP is just one of the things you can do once you have JNDI available).
Yet, here we are, several years later, acting surprised this thing existed and thinking that tests would've helped!? What kind of tests, exactly?!!? I think I am to blame myself, as many other Java developers who actually use log4j, has a good understanding of how it works, knows JNDI and LDAP, yet never connected the dots and noticed what this incredibly stupid feature was making possible.
Open source always trails professional software solutions. Yet always time after time will eventually surpass it as the bleeding edge moves further. Maybe we can view it in such a way that major companies have become too reliant on free open software. If you want secure software, pay for it. The knowledge will eventually flow down to free software because it's ultimately run by hobbyists. I like the way it is and I don't see it changing because so many are just donating free time to open free software. Maybe something we could do is make open source contributions tax deductible (if we could somehow price it accurately)
I would say that this is different from "hard to explain". What is being proposed is essentially "OSS with a paid model for premium support / feature development." It shifts the language from "donations", which companies don't understand, to "consulting", which companies do understand.
It's not completely novel, projects such as openssl and sqlite do offer paid consulting, but it's not normalized among companies to pay for doing so. If Filippo can normalize having OSS be treated as paid consulting engagements I think that would be wonderful for the community.
> OSS with a paid model for premium support / feature development.
Adding features do not reduce likelihood of bugs, if anything the opposite.
It's very difficult to come up with a paid model that specifically encourages a preventative strategy towards bugs and security flaws. Currently the best we have is getting people who care about those things to build software.
Yep. Working for a company that makes paid for software and customers always want more features. It's really fun when paying mutually incompatible features added and the sales people and developers go at it for months trying to figure out how to make it work.
Then, maybe a year later, that feature is no longer the hot new thing and it becomes abandonware inside the application. If you're app isn't cloud based you have no idea if you can rip the feature out or not as you have no idea how many people, if anyone still uses it.
Open market dynamics should in theory change this one way or another. Long term you can't have some code cost $0 while an SVE's code costs $300k+ per year... Reality is open source code is badly mispriced right now.
Maybe there is nothing wrong with the "status quo", maybe we don't need yet another attempt to finance small FOSS projects where it's hard to explain how money will actually solve any of these issues.
Maybe people just need to be more considerate of what they depend upon. And in the case that a popular yet well maintained project has a CVE on day, maybe we need to accept that popularity does not make them invulnerable to bugs, all software has bugs.
</ unpopular realists opinion>