[KronisLV]

> ...the Log4Shell vulnerability only applies to log4j 2.x (so if you stayed with log4j 1.x, and didn't explicitly configure it to use a vulnerable appender, you were safe)

Seems like someone likes to live dangerously: using libraries that haven't been updated since 2012 is a pretty risky move, especially given that if an RCE is discovered now, you'll find yourself without too many options to address it, short of migrating over to the new release (which will be worse than having to patch a single dependency in a backwards compatible manner): https://logging.apache.org/log4j/1.2/changes-report.html

Admittedly, i wrote a blog post called "Never update anything" a while back, even if in a slightly absurdist manner: https://blog.kronis.dev/articles/never-update-anything and personally think that frequent updates are a pain to deal with, but personally i'd only advocate for using stable/infrequently updated pieces of software if they're still supported in one way or another.

You do bring up a nice point about the recent influx of vulnerabilities and problems in the Java ecosystem, which i believe is created by the fact that they're moving ahead at a faster speed and are attempting to introduce new language features to stay relevant and make the language more inviting for more developers.

That said, with how many GitHub outages there have been in the past year and how many other pieces of software/services have broken in a variety of ways, i feel like chasing after a more rapid pace of changes and breaking things in the process is an industry wide problem.

[yardstick]

> using libraries that haven't been updated since 2012 is a pretty risky move

I disagree. Some libraries are just rock solid, well tested and long life.

In the case of log4j 1.x vs 2.x, has there been any real motivator to upgrade? There are 2 well known documented vulnerabilities in 1.x that only apply if you use extensions.

[KronisLV]

A sibling comment mentions the reload4j project, so clearly someone thought that 1.x wasn't adequate to a degree of creating a new project around maintaining a fork. Can't speak of the project itself, merely the fact that its existence supports the idea that EOL software is something that people would prefer to avoid, even if they decide to maintain a backwards compatible fork themselves, which is great to see.

Here's a bit more information about some of the vulnerabilities in 1.x, someone did a nice writeup about it: https://www.petefreitag.com/item/926.cfm

I've also dealt with 1.x having some issues with data loss, for example, https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4... which is unlikely to get fixed:

  DailyRollingFileAppender has been observed to exhibit synchronization issues and data loss.

(though at least in regards to that problem, there are alternatives; though for the most part EOL software implies that no further fixes will be available)

But at the end of the day none of it really matters: those who don't want to upgrade won't do so, potential issues down the road (or even current ones that they're not aware of) be damned. Similarly, others might have unpatched versions of 2.x running somewhere which somehow haven't been targeted by automated attacks (yet) and might continue to do so while there isn't proper motivation to upgrade, or won't do so until it will be too late.

Personally, i dislike the idea of using abandoned software for the most part, when i just want to get things done - i don't have the time to dance around old documentation, dead links, having to figure out workarounds for CVEs versus just using the latest (stable) versions and letting someone else worry about it all down the road. Why take on an additional liability, when most modern tooling and framework integrations (e.g. Spring Boot) will be built around the new stuff anyways? Though thankfully in regards to this particular case slf4j gives you more flexibility, but in general i'd prefer to use supported versions of software.

I say that as someone who actually migrated a bunch of old monolithic Spring (not Boot) apps to something more modern when the versions had been EOL for a few years and there were over a hundred CVEs as indicated by automated dependency/package scanning. It took months to do, because previously nobody actually cared to constantly follow the new releases and thus it was more akin to a rewrite rather than an update - absolute pain, especially that JDK 8 to 11 migration was also tacked on, as was containerizing the app due to environmental inconsistencies growing throughout the years to the point where the app would roll over and die and nobody had any idea why (ahh, the joys of working with monoliths, where even logs, JMX and heap dumps don't help you).

Of course, after untangling that mess, i'd like to suggest that you should not only constantly update packages (think every week, alongside releases; you should also release often) but also keep the surface area of any individual service small enough that they can be easily replaced/rewritten. Anyways, i'm going off on a tangent here about the greater implications of using EOL stuff long term, but those are my opinions and i simultaneously do admit that there are exceptions to that approach and circumstances vary, of course.

[cesarb]

> especially given that if an RCE is discovered now, you'll find yourself without too many options to address it, short of migrating over to the new release

Luckily, there's now an alternative: reload4j (https://reload4j.qos.ch/) is a maintained fork of log4j 1.x, so if you were one of the many who stayed on the older log4j 1.x (and there were enough of them that there was sufficient demand for that fork to be created), you can just migrate to that fork (which is AFAIK fully backward compatible).

(And if you do want to migrate away from log4j 1.x, you don't need to migrate to log4j 2.x; you could also migrate to something else like logback.)