4 ms·

> for a feature we all dislike yet needed to keep due to backward compatibility concerns. It's logging. While logging is extremely important, I think we could

> for a feature we all dislike yet needed to keep due to backward compatibility concerns. It's logging. While logging is extremely important, I think we could all tolerate removing a vulnerable feature. Or, just move the feature to a separate package. I have made bad decisions, we have all made bad decisions. Own them, improve, and celebrate the opportunity to learn and improve. Keeping this around, as a default, was a bad decision. If your enterprise contracts don't want to turn a flag on, then they can always skip upgrading (they generally do regardless).

diroussel 5y ago
They didn’t know it was vulnerable, they just didn’t like it for other reasons. Should maintainers of all core apache libs just remove or disable features they don’t like, when not known to be insecure? That said, log4j2 isn’t that old. Not sure why this was added in the first place. At the very least it’s a performance issue.
- wpietri 5y ago
  > Should maintainers of all core apache libs just remove or disable features they don’t like, when not known to be insecure? I'd bet more will start doing so. If nobody is excited to keep the feature up and any unloved code contains risks, getting rid of it seems fine to me. If companies want that code maintained, they can pay up or get one of their people to do it.
- zamalek 5y ago
  > Should maintainers of all core apache libs just remove or disable features they don’t like, Why not? I can just go into a parity package.
- matkoniecz 5y ago
  > Should maintainers of all core apache libs just remove or disable features they don’t like, when not known to be insecure? If noone funds their development and they maintain it for free? Then yes, why not.
- manquer 5y ago
  If you are not being paid for it why build features you don't like? That is what you do in your day job! Your hobby project should atleast should make you happy ?
orangecat 5y ago
Keeping this around, as a default, was a bad decision. Definitely. But really, they were screwed once it had shipped. They could and should have disabled it in an update long ago, but then anyone who read the release notes or the code would know how to exploit the millions of un-updated systems.
dehrmann 5y ago
One place I worked used syslog to ship important analytics data from services to Kafka. log4j is a reasonable choice for logging to syslog from Java (but let's be honest, you should be on Logback). Now, using jndi as part of this? That's getting a little too clever.
superjan 5y ago
I can imagine the maintainers being scared of silently breaking the workflow and monitoring for some users. If you change this feature to opt-in, you may silently break the alerting system users built on top of this feature, and then you get the heat for breaking a somebody’s IT system(a hospital maybe), just because you hated that feature. That it had an RCE would not be known at the time. In a perfect world, the feature would have been an option from the start, but in that same perfect world, the downstream users would be diligent and check release notes before upgrading. You might, but many of your colleagues don’t, they just upgrade, and complain when their system breaks.
- whyever 5y ago
  That's why you have versioning: removing the feature would be a breaking change and indicated as such.

diroussel 5y ago

They didn’t know it was vulnerable, they just didn’t like it for other reasons. Should maintainers of all core apache libs just remove or disable features they don’t like, when not known to be insecure? That said, log4j2 isn’t that old. Not sure why this was added in the first place. At the very least it’s a performance issue.

wpietri 5y ago
> Should maintainers of all core apache libs just remove or disable features they don’t like, when not known to be insecure? I'd bet more will start doing so. If nobody is excited to keep the feature up and any unloved code contains risks, getting rid of it seems fine to me. If companies want that code maintained, they can pay up or get one of their people to do it.
zamalek 5y ago
> Should maintainers of all core apache libs just remove or disable features they don’t like, Why not? I can just go into a parity package.
matkoniecz 5y ago
> Should maintainers of all core apache libs just remove or disable features they don’t like, when not known to be insecure? If noone funds their development and they maintain it for free? Then yes, why not.
manquer 5y ago
If you are not being paid for it why build features you don't like? That is what you do in your day job! Your hobby project should atleast should make you happy ?

orangecat 5y ago

Keeping this around, as a default, was a bad decision. Definitely. But really, they were screwed once it had shipped. They could and should have disabled it in an update long ago, but then anyone who read the release notes or the code would know how to exploit the millions of un-updated systems.

dehrmann 5y ago

One place I worked used syslog to ship important analytics data from services to Kafka. log4j is a reasonable choice for logging to syslog from Java (but let's be honest, you should be on Logback). Now, using jndi as part of this? That's getting a little too clever.

superjan 5y ago

I can imagine the maintainers being scared of silently breaking the workflow and monitoring for some users. If you change this feature to opt-in, you may silently break the alerting system users built on top of this feature, and then you get the heat for breaking a somebody’s IT system(a hospital maybe), just because you hated that feature. That it had an RCE would not be known at the time. In a perfect world, the feature would have been an option from the start, but in that same perfect world, the downstream users would be diligent and check release notes before upgrading. You might, but many of your colleagues don’t, they just upgrade, and complain when their system breaks.

whyever 5y ago
That's why you have versioning: removing the feature would be a breaking change and indicated as such.