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

Log4j: The pain just keeps going

thenewstack.io

Post reply on HN
Print view View original

151–160 of 291 posts

Re: Log4j: The pain just keeps going

#151

Post by gnulinux »

ClumsyPilot wrote: post #115
wyager wrote: post #53

Earlier quoted context omitted.

> The current software engineering paradigm has no meaningful answer to this The answer is to stop using garbage software written in garbage languages. Of course the current environment is too high-time-preference for this to be economical in many industries. We have lightweight-to-heavyweight formal systems which can almost completely or literally completely eliminate issues of the type seen with log4j, but due to t…

'software written in garbage languages' well, back to the mainframe it is then

Quite the opposite, we have very safe languages now in 2022. Any software that's not written in Rust or Haskell has to explain the trade-off of being written in an unsafe language. Of course the industry will still use unsafe languages, but we lack the awareness that we're intentionally writing garbage software in garbage languages that should be treated as radioactive material in any context where safety matters. If you pick a language without understanding this point, you're part of the problem. If you pick an unsafe language understanding that X matters more than safety, then you saw all of this coming and you made an educated gamble.

Re: Log4j: The pain just keeps going

#152

Post by ClumsyPilot »

jsiaajdsdaa wrote: post #133
ClumsyPilot wrote: post #113

Earlier quoted context omitted.

problem: food contaminated solution: stop eating

solution: find uncontaminated food, or make it yourself

option 1 - we and farmers, as professionals are responsible for supplying stuff that is not dangerous and works as it should

Option 2 - which you are advocating - it's every man for himself and we decent into socity of warring tribes of hunter hatherer or subsitence farming at best

Re: Log4j: The pain just keeps going

#153

Post by bick_nyers »

BrainVirus wrote: post #37

If you automatically update your dependencies all the time, you will constantly get new bugs, issues and sometimes even malware. If you don't update your dependencies all the time, you will be vulnerable to old bugs and issues. The current software engineering paradigm has no meaningful answer to this , no matter what "security experts" tell you. In a sane industry this realization would lead to a change of the parad…

There is likely never going to be an approach that yields 0 vulnerabilities, so instead we should be more focused on minimizing the risk as much as possible. There is a middle ground and nuance between never update and always update, just as there is a nuance in how much and what you duck tape together.

Not sure if it's the best, but my current approach is to target major revisions/versions with ABI/API compatibility as viable candidates, and update always, but at a lagged rate, ideally allowing enough time to pass for vulnerabilities to be surfaced in those versions. Log4j is a tough case due to how far back it goes version-wise, but you simply can't win them all.

Another important way to minimize risk is to have a strong ability to provide a corrective action. If replacing the version or the entire dependency of a library you use takes a significant engineering effort, then you are arguably at a higher risk due to that than you are in your decision to never vs. always update.

Re: Log4j: The pain just keeps going

#154

Post by twunde »

ClumsyPilot wrote: post #111
ruined wrote: post #98

Earlier quoted context omitted.

there was no market demand for building codes, either. that's why they're laws

bbut but mah free market gave us fire escapes attached to every building in new york, and they were made of wood!

I know you're being sarcastic, but this reminded me of Tanya Reilly's _great_ talk "The history of fire escapes: How to fail". There's a recording up at https://www.infoq.com/presentations/history-fire-escapes-res...

Re: Log4j: The pain just keeps going

#155

Post by kllrnohj »

jewel wrote: post #20
skybrian wrote: post #11

Earlier quoted context omitted.

The situation for Go seems to have gotten a bit better with Go 1.18. Go binaries now include the versions of all the modules in them, and this can be listed with the "go version" command. That won't help you rebuild the binary, but at least you can find them.

That's fantastic. Since Go has gone all-in on static compiling, it'd be awesome if they made it possible to update a dependency without recompiling (or even having the source code for) the rest of the program. In addition to making it easier to do security updates in situations like log4j, it'd also make it easy to comply with LGPL license terms.

That doesn't seem possible. The benefits of static linking are that unused methods, symbols, etc... can be stripped as well as cross-library optimizations like in-lining. There's not necessarily going to be library lines left at all, at least not in any way that looks anything like upstream. And it's also going to vary from binary to binary, depending on what exactly they used from the dependency.

What you're describing would be more akin to shared linkage just in a single blob. That seems like it'd be a worst-of-both-worlds result.

Re: Log4j: The pain just keeps going

#156

Post by smarx007 »

vbezhenar wrote: post #88
hyperman1 wrote: post #27

I never understood where log4j 2 was supposed to fit in the ecosystem. * We had log4j 1, which was good enough for most use cases and everywhere. * We had slf4j/logback, which was from the same authors, and broke backward compatibility but gave us a fundamentally better design. * We had java.util.logging, which while braindead was builtin to Java and hence available everywhere. *We had commons logging, which was neve…

Log4j2 does have some legitimate improvements over logback. These days you don't need anything fancy, just spew logs into stdout and something will capture it to your ELK, so those loggers seem obsolete indeed. Java need standard logging with slightly improved ergonomics and that's about it.

> Java need standard logging with slightly improved ergonomics

That's exactly what JDK9+ java.lang.System.Logger is. See https://stackoverflow.com/questions/59976828/difference-betw...

Re: Log4j: The pain just keeps going

#157

Post by kodah »

SomeCallMeTim wrote: post #117
BrainVirus wrote: post #37

If you automatically update your dependencies all the time, you will constantly get new bugs, issues and sometimes even malware. If you don't update your dependencies all the time, you will be vulnerable to old bugs and issues. The current software engineering paradigm has no meaningful answer to this , no matter what "security experts" tell you. In a sane industry this realization would lead to a change of the parad…

>"Use a build tool to do dependency checks!" > >And then what? > >"Only update libraries if they have vulnerabilities." > >So, should this be a manual process where I have to dig through obscure warnings every time I build something? > >"No, you can automate it!" > > Congrats, you've just outsourced the decision making process about which versions of libraries to use to some 3d party. You've also made your build proc…

I think people's experiences will vary with tools like this due to company policy. For instance, your company allows you to make decisions about whether a vulnerability pertains to you, but many don't. I think that's how these tools become "noise", because the only option an engineer is given by leadership is to comply to the tool.

At this point, I think a lot of problems in software are actually misaligned or misincentivized policy gone awry. When you read about them on forums they look technical, but they're not.

Re: Log4j: The pain just keeps going

#158

Post by sporkland »

jacobyoder wrote: post #12

Had to deal with some automated scan tool telling a client "you have log4j - you're vulnerable!" when... we didn't. A project was including a dependency on SLF4J and that project pulled in slf4j-log4j (IIRC). But it was not configured, wasn't compiled in to the final jar, and ... even it was, it was very old log4j (1.1 or 1.2 IIRC?). The vulnerability didn't affect that older version. We had to spend a week back and…

Log4j-api isn't vulnerable and the slf4j-log4j bridge depends on it. Log4j-core is. All of our internal security scanners failed to make this distinction so we had to post filter ourselves.

Re: Log4j: The pain just keeps going

#159

Post by jsiaajdsdaa »

ClumsyPilot wrote: post #152
jsiaajdsdaa wrote: post #133

Earlier quoted context omitted.

solution: find uncontaminated food, or make it yourself

option 1 - we and farmers, as professionals are responsible for supplying stuff that is not dangerous and works as it should Option 2 - which you are advocating - it's every man for himself and we decent into socity of warring tribes of hunter hatherer or subsitence farming at best

option 2 is the only possible state of reality, because it is never possible to guarantee that everything work in every instance

let the buyer be aware

Re: Log4j: The pain just keeps going

#160

Post by aclatuts »

alfalfasprout wrote: post #122
BrainVirus wrote: post #37

If you automatically update your dependencies all the time, you will constantly get new bugs, issues and sometimes even malware. If you don't update your dependencies all the time, you will be vulnerable to old bugs and issues. The current software engineering paradigm has no meaningful answer to this , no matter what "security experts" tell you. In a sane industry this realization would lead to a change of the parad…

We actually are running into this exact problem with running production ML workloads and despite anyone's claims it's not a solved problem. In fact, this log4j mess is a cake walk in comparison. The issue: ML workloads are very sensitive to the exact version of a framework/library used and these frameworks/libraries are not stable despite what their semantic version says. So what do you do when you have a python vuln…

I find Python is very prone to a lot of breaking changes even with minor version changes. And not just that, even minor versions have to match up specifically with another libraries minor version. It seems to be a community or ecosystem problem with Python, which is why I avoid Python as much as possible.

In every other ecosystem when minor version are updated there are very rarely issues, and there are little issues with compatibility with minor versions of libraries.

Post reply on HN