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

31–40 of 335 posts

Re: Third High Severity CVE in Log4j Is Published

#31

Post by dylan604 »

grafs50 wrote: post #11
dylan604 wrote: post #5

Earlier quoted context omitted.

>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…

I don't understand what the problem is if you don't use the code. Why does it matter to you if it gets fixed?

I use services that do use that code though, so I am affected when it goes down

Re: Third High Severity CVE in Log4j Is Published

#32

Post by ashtonkem »

Hallucinaut wrote: post #15
jacquesc wrote: post #13

Earlier quoted context omitted.

Thanks to Log4J developers for turning me off to Java 20yrs ago due to their horrible API design and developer experience. Does not shock me that this security vulnerability happened, but it did shock me that so many people kept using this awful library. I thus enjoyed a development career (mostly) free from this kind of needless pain and suffering.

log4j2 has little to do with the log4j you claim turned you off 20 years ago and almost no one works directly to the logging library API rather than an slf4j facade.

Slf4j is one of the two examples I point to for really great java design. It's broken down into one jar for the no-op interfaces, and other jars for the various implementations. This lets library owners instrument their libraries for logging without having to make a final decision on the actual logging library and its settings. It's great.

The other example for those that are curious is micrometer. The basic API and the implementations (prometheus, statsd, etc.) are separate jars.

Re: Third High Severity CVE in Log4j Is Published

#35

Post by peterkelly »

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 for complicated things (e.g. crypto libraries). But logging, really?

Software development culture today is too quick to adopt a huge tree of dependencies of unknown quality, rather than thinking about how to minimize dependencies to only those truly necessary. The leftpad fiasco was but an extreme example of this, but I see it all the time, and it seems probable that there are hundreds (maybe even thousands) of similarly severe problems out there in widely used dependencies that we just don't know about yet.

Re: Third High Severity CVE in Log4j Is Published

#36

Post by johnisgood »

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…

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.

Re: Third High Severity CVE in Log4j Is Published

#37

Post by jacquesm »

ashtonkem wrote: post #34
dreyfan wrote: post #27

I’m enjoying the Apache Software Exploit Advent Calendar

I am not. Although one of my direct's decisions to setup a parent pom to manage versions across all our apps is paying back dividends this week.

Smart person!

Re: Third High Severity CVE in Log4j Is Published

#39

Post by hulitu »

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…

Why bother to implement something when someone else did it ? Why bother thinking to check the quality of the code when someone else did it ?

Re: Third High Severity CVE in Log4j Is Published

#40

Post by RHSeeger »

jeffbee wrote: post #22
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…

I'm baffled by these claims that we should compensate the authors and maintainers of what has been conclusively shown to be software too dangerous to exist. It has the same problem as calls to pay the maintainers of openssl. No amount of money is going to impart good taste and best practices onto these projects. The uncomfortable truth is these libraries need scratch rewrites with better authors.

Saying things like "I don't like this software because " is reasonable; it can be considered constructive criticism, especially if you include a way it could be done better. Heck, even just "I think it's too complicated to use, and the underlying code base needed to support that complexity lends itself to bugs that can be exploited" would be better.

Saying things like "No amount of money is going to impart good taste and best practices onto these projects" is insulting the people who wrote it with no real basis. It's not helpful and it makes you (and some other people in the thread) sound like a jerk.

Post reply on HN