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

141–150 of 291 posts

Re: Log4j: The pain just keeps going

#141

Post by feffe »

brundolf wrote: post #105
AshamedCaptain wrote: post #85

Earlier quoted context omitted.

I still think that betteer ABI/API stability & control _is_ the ideally better solution, but even if I'm a fan of plain old C / sonames dependency management, I'll readily admit that very few people actually do any type of API promises these days, much less API.

ABI/API stability != behavioral stability, though. I can give you a dependency with exactly the same interface, that will still break your software. It's not a solution (even if it helps with one piece of the puzzle) The only complete solution would be static analysis (read: type systems) that can guarantee everything about some code's contract/behavior relative to the caller. Short of that, it's just going to contin…

I think a mindset that could work is to accept software as done. This is hard but for foundational stuff it could work well. Only fix bugs in such software. Try to set a scope what the software should do, build it, then do maintenance on it. Supersede it entirely to add new functionality.

That's my armchair take on it.

Re: Log4j: The pain just keeps going

#142

Post by alfalfasprout »

xmprt wrote: post #139
alfalfasprout wrote: post #122

Earlier quoted context omitted.

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…

Is this an issue of code stability or do these libraries have leaky abstractions that cause issues with models trained on previous version, because the library implementation changed and since ML has low explainability, it's hard to tell how the change impacts the model performance? eg. making a library run faster or use a slightly different parameter internally causes some floating point imprecision that cascades in…

Unfortunately it's all of the above. Sometimes the code isn't stable (eg; a library method changed), sometimes the behavior has changed (eg; same library method but now it has a different behavior), and sometimes it has some other unwanted effect (the computation produces a totally different result, it runs way slower, or something else).

With a service it's all much easier because you can have pretty robust integration tests and you're good to go. With an ML model it's a lot trickier because even if you have sample payloads and responses there might be other payloads you didn't think about that could cause issues. Or it might rear its ugly head when you finally retrain the model and suddenly model performance is crap.

Re: Log4j: The pain just keeps going

#143

Post by agumonkey »

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…

And there's the tangling of dependencies. One fix in one lib may cause a bug in another that isn't maintained.

Re: Log4j: The pain just keeps going

#144

Post by agumonkey »

hinkley wrote: post #134
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…

When I worked on a code signing app, which is arguably some of the highest stakes of almost anything I've worked on, we came around to an agreement that one ticket a month would be assigned to upgrade libraries, and we rotated that responsibility. We didn't stipulate what library, we didn't even stipulate which application in the suite (though it was assumed that you were likely to chose your primary application as t…

> we rotated that responsibility

how did that go ? I often wanted to do it but never got to submit the idea.

Re: Log4j: The pain just keeps going

#145

Post by Aperocky »

shagie wrote: post #77
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…

> Then apache decides to put new people on log4j, do a backward incompatible v2 design that nevertheless is worse than slf4j. Why? slf4j itself isn't a logging framework. It's a facade to logging frameworks. Simple Logging Facade for Java ( https://www.slf4j.org ) It needs a logging framework behind it - log4j, log4j2, logback, commons, JUL. The question is "why do log4j2?" Logback went from the log4j1.x path ( https…

> Log4j2 has a lot of features

Apache projects in general have this feature creep seeping into every single one of their products that I have used.

It's just hard to trust apache projects now.

Re: Log4j: The pain just keeps going

#146

Post by bastardoperator »

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…

This is basically what Dependabot on GitHub does too. If it finds a vulnerability it creates a PR that you can decide to apply. It's automated to the extent that it's easy but it's not making or forcing changes on you. A human is still in control.

Re: Log4j: The pain just keeps going

#147

Post by jeroenhd »

ChrisMarshallNY wrote: post #125

> Welcome to how we use open source code. That’s a big reason Software Bills of Materials (SBOM) have become essential for securing the software supply chain. I tend to do this, but it's pretty damn easy for me. I have a "2-level-dependency" rule that I generally go by, these days. i.e., Each dependency can have only one dependency, and that dependency can't have any others. The main way that I deal with it, is to wr…

I like the "2-level-dependency" rule, but what do you do when one of your dependencies gains more dependencies? Do you stop updating and start migrating to something else, or maybe maintain a fork of your own?

It's a very nice concept, but I kind of have my doubts about maintainability.

Re: Log4j: The pain just keeps going

#148

Post by laughingbovine »

shepherdjerred wrote: post #128
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…

> So the exact software you compile will depend on whether or not you can connect to a 3d party service? Do you understand the actual implications of this? This is already true with the vast majority of software using any an online software repository, e.g. Go, NodeJS, Java, Rust, etc.

Yeah but you can cache the packages or store them in some fashion. I've seen JAR files in git repos far too many times...

With security, you need some online service so you can find the new CVEs every day.

Re: Log4j: The pain just keeps going

#149

Post by ChrisMarshallNY »

jeroenhd wrote: post #147
ChrisMarshallNY wrote: post #125

> Welcome to how we use open source code. That’s a big reason Software Bills of Materials (SBOM) have become essential for securing the software supply chain. I tend to do this, but it's pretty damn easy for me. I have a "2-level-dependency" rule that I generally go by, these days. i.e., Each dependency can have only one dependency, and that dependency can't have any others. The main way that I deal with it, is to wr…

I like the "2-level-dependency" rule, but what do you do when one of your dependencies gains more dependencies? Do you stop updating and start migrating to something else, or maybe maintain a fork of your own? It's a very nice concept, but I kind of have my doubts about maintainability.

I use my own dependencies. I've written many of them. Some of them, go "deeper," but only in dependencies that I authored.

Here's the dependency manifest from the app I'm working on now (From my localization file):

    // MARK: -
    // MARK: - DO NOT TRANSLATE BELOW THIS LINE -
    // MARK: -
    "SLUG-VERSION-BMLT"                             =   "BMLTiOSLib: 1.4.2";
    "SLUG-VERSION-KEYCHAINSWIFT"                    =   "KeychainSwift: 20.0.0";
    "SLUG-VERSION-LGVCLEANTIME"                     =   "LGV_Cleantime: 1.3.5";
    "SLUG-VERSION-UICLEANTIME"                      =   "LGV_UICleantime: 1.1.1";
    "SLUG-VERSION-AUTOFILL"                         =   "RVS_AutofillTextField: 1.3.0";
    "SLUG-VERSION-GCD"                              =   "RVS_BasicGCDTimer: 1.5.0";
    "SLUG-VERSION-CHECKBOX"                         =   "RVS_Checkbox: 1.2.0";
    "SLUG-VERSION-OBSERVER"                         =   "RVS_GeneralObserver: 1.1.0";
    "SLUG-VERSION-GST"                              =   "RVS_Generic_Swift_Toolbox: 1.10.1";
    "SLUG-VERSION-MB"                               =   "RVS_MaskButton: 1.2.0";
    "SLUG-VERSION-PP"                               =   "RVS_Persistent_Prefs: 1.3.1";
    "SLUG-VERSION-UKT"                              =   "RVS_UIKit_Toolbox: 1.1.5";
    "SLUG-VERSION-WHITEDRAGON"                      =   "White Dragon SDK: 3.2.2";
The only one of those that I didn't write, was KeychainSwift[0]. It makes dealing with the Keychain easy, and is a very simple dependency. If it went off the rails, I'd write something like it, myself.

All the others, are in my own repos, as top-shelf-quality open-source modules.

[0] https://github.com/evgenyneu/keychain-swift

Re: Log4j: The pain just keeps going

#150

Post by seoaeu »

feffe wrote: post #141
brundolf wrote: post #105

Earlier quoted context omitted.

ABI/API stability != behavioral stability, though. I can give you a dependency with exactly the same interface, that will still break your software. It's not a solution (even if it helps with one piece of the puzzle) The only complete solution would be static analysis (read: type systems) that can guarantee everything about some code's contract/behavior relative to the caller. Short of that, it's just going to contin…

I think a mindset that could work is to accept software as done. This is hard but for foundational stuff it could work well. Only fix bugs in such software. Try to set a scope what the software should do, build it, then do maintenance on it. Supersede it entirely to add new functionality. That's my armchair take on it.

Adding features to existing software is much cheaper than writing entirely new software (not to mention the cost to switch!) At the same time, new features in low level software can unlock substantial value. Say a new API that speeds up your app by 1% or cuts down on further development time by a small fraction.
Post reply on HN