4 ms·

Would more time or money prevented the log4j bug? If anything that strikes me as coming from too much time spent on overarchitecting something.

by finnh 5y ago

jjoonathan 5y ago
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.
- watwut 5y ago
  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.
taberiand 5y ago
Money spent on dedicated testing might have discovered it earlier perhaps?
- jsiepkes 5y ago
  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.
  - brabel 5y ago
    Exactly, the JNDI feature has been on the docs for everyone to see for several years: https://logging.apache.org/log4j/2.x/manual/lookups.html https://logging.apache.org/log4j/2.x/manual/lookups.html 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.
- mro_name 5y ago
  I don't think testing is the silver bullet here – it's about system boundary awareness.

Would more time or money prevented the log4j bug? If anything that strikes me as coming from too much time spent on overarchitecting something.

by finnh 5y ago

Would more time or money prevented the log4j bug? If anything that strikes me as coming from too much time spent on overarchitecting something.

jjoonathan 5y ago

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.

watwut 5y ago
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.

taberiand 5y ago

Money spent on dedicated testing might have discovered it earlier perhaps?

jsiepkes 5y ago
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.
- brabel 5y ago
  Exactly, the JNDI feature has been on the docs for everyone to see for several years: https://logging.apache.org/log4j/2.x/manual/lookups.html https://logging.apache.org/log4j/2.x/manual/lookups.html 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.
mro_name 5y ago
I don't think testing is the silver bullet here – it's about system boundary awareness.