4 ms·
There is no reason to believe that money would actually solve the issue, and maybe even exacerbate it. The log4j issue is product debt, similar to the sqlite f
by throwaway47292 5y ago
There is no reason to believe that money would actually solve the issue, and maybe even exacerbate it.
The log4j issue is product debt, similar to the sqlite fts tokenizer exploit, and a lot of the openssl exploits, features that are rarely used, and are in the codebase for "no good reason" (from the majority of user's standpoint)
I think the way to make for those things to happen less, is in fact, to code less, and make more small things rather than one giant bloat of features. Paid or not paid, security becomes near impossible after certain amounts of interconnected components.
- throwdbaaway 5y agoI agree with you, but at the same time I am also a little worry that this log4j2 exploit may inadvertently push us to the other extreme. Now every time I want some essential features to be added to a library, the log4j2 exploit will be brought up as a knee-jerk reaction. At least we already got https://github.com/mattermost/logr https://github.com/mattermost/logr, otherwise there could be years before we get to have a golang logging library with async logger.
- csande17 5y agoExactly. If we paid people to maintain log4j, they'd try to justify their existence by writing more code and shipping it in log4j. But log4j doesn't need more code to be secure, it needs dramatically LESS code! The correct answer here isn't "pay people to make log4j even worse", it's "don't use log4j".
- seoaeu 5y agoIdentifying and removing superfluous code seems like exactly the kind of unexciting work that a developer might only consider if they are compensated.
- throwaway47292 5y agoHow many developers have you seen to do that? Removing code is twice harder than writing it. Sometimes even more than twice, not only technically, but politically.