[kube-system]

Under a microscope, maybe.

But if you had a "perfect" piece of software that used Log4j in 2020, it wouldn't have been perfect for long.

Unfortunately, there's a lot of reasons that software needs maintenance, even if it was thought to be perfect when it was originally written.

Hardware changes. The software landscape changes. Dependencies are deprecated, or are found to have their own problems. Vulnerabilities are discovered. Vulnerabilities are found that aren't even the fault of your software, maybe they are a flaw in the hardware your software runs on, and the only way to fix it is via a software mitigation. These are all real things that happen to otherwise perfect software.

[ridifndnwj]

Ironically if you didn’t upgrade from 1.x you didn’t get the new features or the bug you’re referring to

[kube-system]

2.x had been out for about six years by the time the vulnerability was discovered.

[ridifndnwj]

And 1.x was and has been logging for a decade or more before that which is why I thought it relevant to the ‘no need to upgrade’ discussion

[kube-system]

The world didn't stop building new software for that 6 year period, is my point. One would have picked the latest version to build something during that time period.

[socksy]

Plenty of Clojure projects are "done" (the only community I'm aware of that actually believes in this) that presumably specified the vulnerable log4j versions. In reality, it's not an issue, because you can deal with it in your own deps.edn/project.clj/maven.xml, by excluding the dependency, or overriding it with a newer one.

[kube-system]

> In reality, it's not an issue, because you can deal with it in your own deps.edn/project.clj/maven.xml, by excluding the dependency, or overriding it with a newer one.

This is maintenance. Maintenance is not an issue if you deal with it, if you don't deal with it, then it is an issue.