Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Third High Severity CVE in Log4j Is Published

logging.apache.org

Post reply on HN
Print view View original

61–70 of 335 posts

Re: Third High Severity CVE in Log4j Is Published

#61

Post by samhw »

dylan604 wrote: post #5
alanfranz wrote: post #3

Earlier quoted context omitted.

This attitude should stop. They're volunteers. It's open source. Users are required to use such piece of software at their own will and risk. Log4j didn't ever get a single penny from most (all?) of their users, and now they should take all the blame. Why? The disclosure process was terrible, they clearly had no time to perform a thorough validation of the hotfixes, and this is the result. Why didn't anybody else ste…

>But then, it's log4j developers and Apache that should be blamed. Bah. That's SO pretentious. Um, yeah. They wrote the idiotic code that allowed this to happen. Who should get the blame then, the users? Duh, no. Should the hackers taking advantage of the exploit? Maybe, some, but they wouldn't be able to do it if the code wasn't so badly wrritten. >Why didn't anybody else step up to help them? To me, this is the pre…

This comment isn't even consistent with itself. First you say:

> Who should get the blame then, the users? Duh, no.

And then you say:

> I don't use the code, so why in the world should I be expected to fix the code? Do you use the code? Why didn't YOU fix it?

Just take a step back, stop trying to throw shade at anyone and everyone, and look at the situation analytically.

I don't really see the point of these comments. The people who make a contribution to the world are the people who see a problem and take practical steps to fix it and improve the situation, rather than the people who see a problem and immediately descend into finger-pointing and shouting.

Re: Third High Severity CVE in Log4j Is Published

#62

Post by dragonwriter »

peterkelly wrote: post #35

Here's what I don't get: What is so complicated about logging that you can't implement the necessary functionality in your own codebase, and instead have to adopt a third-party library? The latter option represents a liability, which in this case (as with others) has shown can be a tremendous risk. Is the time saving really worth it, at the cost of risking disasters like this? I get that the tradeoff it is worth it f…

> What is so complicated about logging that you can't implement the necessary functionality in your own codebase, and instead have to adopt a third-party library?

(1) Coordinating with dependencies requires at a minimum a common API (which, in a statically typed language, means a library providing at least the interface).

(2) Configurability to log to different destinations and with different formats, which you eventually tend to want on major or long-lived projects, can be fiddly, as can the specifics of different formats and targets. Each of the bits is simple, but added up it's a lot over time, and reinventing the wheel, the axle, the tire, and the air pump for it just doesn't make a lot of sense. Especially given the need for a library for #1, it's best to get the core functionality together with it, and the peripheral pieces either together or as plugins, and only solving unique problems, if you have them.

Re: Third High Severity CVE in Log4j Is Published

#64

Post by tomohawk »

It's been a minute since I primarily developed in Java, but back then we had switched away from log4j in favor of slf4j / logback. These were written by the author of log4j. We switched because they were significantly simpler than log4j.

Switching over merely involved changing the jar files we used, and redoing the config.

Re: Third High Severity CVE in Log4j Is Published

#65

Post by [deleted] »

sahila wrote: post #60
johnisgood wrote: post #36

Earlier quoted context omitted.

Whenever I write C, the goal is to have no or very few dependencies. When I see projects written in C, one of the features is that it has no dependencies. This is a good thing. I do not know why we are steering away from this.

It's pretty easy to understand really; it allows engineers to focus on other things and do more. It's not nefarious or because people are always lazy, but the choice between spending time on a business feature or a logging library when one exists that is widely used is hard to sell.

[deleted]

Re: Third High Severity CVE in Log4j Is Published

#66

Post by nimrody »

It's amazing that this library is used by so many large enterprises yet none of them made an effort to thoroughly audit the code (actually, it looks like Alibaba reported the first one. But the point stands that the code was used for so long and by so many.)

Re: Third High Severity CVE in Log4j Is Published

#67

Post by tomohawk »

peterkelly wrote: post #35

Here's what I don't get: What is so complicated about logging that you can't implement the necessary functionality in your own codebase, and instead have to adopt a third-party library? The latter option represents a liability, which in this case (as with others) has shown can be a tremendous risk. Is the time saving really worth it, at the cost of risking disasters like this? I get that the tradeoff it is worth it f…

We asked the same thing about log4j over 10 years ago. We spent an hour or two and switched to slf4j / logback. It's written by the original author of log4j, and has a compatible api. Much simpler and much more understandable.

Re: Third High Severity CVE in Log4j Is Published

#68

Post by throwaway19937 »

Kreotiko wrote: post #9

If information security people would spend the same amount of time they are spending complaining about this vulnerability trying to educate their organisations on the importance of supporting open source solutions they depend on we wouldn’t be in this situation. I am sick of reading of very senior people complaining about the impact this vulnerability has had on their week when their companies don’t even contribute a…

> If information security people would spend the same amount of time they are spending complaining about this vulnerability trying to educate their organisations on the importance of supporting open source solutions they depend on we wouldn’t be in this situation.

Security teams are stuck with securing the tire fire; they didn't choose the library or platform. If anyone should be advocating for supporting open source, it's the developers who benefit by using open source libraries.

Re: Third High Severity CVE in Log4j Is Published

#69

Post by hirako2000 »

nimrody wrote: post #66

It's amazing that this library is used by so many large enterprises yet none of them made an effort to thoroughly audit the code (actually, it looks like Alibaba reported the first one. But the point stands that the code was used for so long and by so many.)

Each enterprise doesn't only use this common library, it uses a few more hundreds. If the point of pulling libraries is to save tremendous time in not having to write them, I can assure you managers aren't keen in wasting their gains in looking deeply into what's inside. Spotting the flaws, even with careful reviewing is still unlikely to happen, and would benefit the community at wide over their selfish interests.Enterprises use of open source doesn't adhere to the open source étiquette.

Re: Third High Severity CVE in Log4j Is Published

#70

Post by WFHRenaissance »

peterkelly wrote: post #35

Here's what I don't get: What is so complicated about logging that you can't implement the necessary functionality in your own codebase, and instead have to adopt a third-party library? The latter option represents a liability, which in this case (as with others) has shown can be a tremendous risk. Is the time saving really worth it, at the cost of risking disasters like this? I get that the tradeoff it is worth it f…

> implement the necessary functionality in your own codebase

Sir, you might have just extended all of our careers by at least a decade. We salute you.

I agree that developers are too quick to put themselves at the mercy of 3rd parties, but it's a risk-dollar trade off we'll continue to make because reinventing the wheel each time would sap our margins.

Post reply on HN