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

281–290 of 291 posts

Re: Log4j: The pain just keeps going

#281

Post by LaGrange »

WesolyKubeczek wrote: post #249
kelnos wrote: post #226

Earlier quoted context omitted.

... which is why the parent is (IMO correctly) claiming that the grandparent's assertion is incorrect that a Debian package is a "single file deployment".

I think both grandparent you’re referring to and its parent are lost in the woods.

Oh no, no I'm not, and the point of the joke was that a deb is as much of a single file as your compiled go thing. It's... well, it's a single file, it's a single artifact.

And yes, it has dependencies! So does your go file, I'm afraid.

Re: Log4j: The pain just keeps going

#282

Post by preseinger »

kelnos wrote: post #231
preseinger wrote: post #192

Earlier quoted context omitted.

> You hear there's this big vuln affecting Go programs. This isn't relevant. What's relevant is if any of the specific programs I am responsible for have a vulnerability. If so, I need to update those specific programs. The notion of implementation language, shared library, dependency, these are all abstraction leaks. The atomic unit of responsibility, at the machine level, is program/service.

I think that's the parent's point. The hypothetical big announcement that this hypothetical "Log4Go" library has a vulnerability will not include a comprehensive list of all applications that use the library, so then we have to hope that the developers of every single application that uses Log4Go hears about the vulnerability, updates their software, makes a new release, and then notifies all their users somehow. Alt…

> The hypothetical big announcement that this hypothetical "Log4Go" library has a vulnerability will not include a comprehensive list of all applications that use the library,

Nor should it. A dependency should be encapsulated by its consumers. A vulnerability that leaks to the consumer application is a bug in the consumer application.

> The safest thing would be for every application to dynamically link to a system-provided version of Log4Go,

Unfortunately this means that any application which uses Log4Go cannot make any definitive assertions about the specific code which is executed by their distributed artifact. This is a problem, and the cost of this problem is far higher than the benefits conveyed by dynamic linking. The future of application distribution is absolutely static linking.

> "I have to vendor library X into my application, because I'm afraid that the system copy will get updated to a version that breaks my app". Well then, maybe you shouldn't use a library whose author can't abide by semver and provide a reasonably-strong promise that minor and patch version updates won't break things. Otherwise you are just outsourcing your problems to your users.

As a software producer, it should not be possible for a dependency to impact my users without my knowledge.

It is infeasible to rely on any specific level of versioning stability from my dependencies. Every dependency I adopt represents a risk which I am taking on.

Re: Log4j: The pain just keeps going

#283

Post by skjoldr »

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, should this be a manual process where I have to dig through obscure warnings every time I build something?

Also known as doing your job.

Re: Log4j: The pain just keeps going

#284

Post by wyager »

shikoba wrote: post #187
wyager wrote: post #99

Earlier quoted context omitted.

I'm not any of those guys, and of those 3 rust is by far the least garbage. Garbagicity is a spectrum.

I was sure reading your first post that you will propose rust. Rust users never cease to amaze me.

I'm not a "rust user" any more than I'm a java user (less, in fact). Your heuristic is probably picking up on the fact that people who pay attention to things like this tend to have correlated opinions.

Re: Log4j: The pain just keeps going

#285

Post by TheCapn »

kelnos wrote: post #213
TheCapn wrote: post #175

Earlier quoted context omitted.

Engineering Code of Ethics dictate that safety of public and environment is paramount. I know that's true for my P.Eng governing body; it is written into our bylaws. I'm sure its the same for most others as well. I think until Software Engineering catches up in this regard with traditional Engineering disciplines we'll continue to see issues arise from the software realm. As much as the self-titled "Engineers" procla…

I've always been uncomfortable calling myself a "software engineer" for this reason, and usually refer to myself as a "software developer". Most of the job listings I see at various companies use "engineer" though, and so my official title ends up being "engineer", so that's what I end up putting on my resume. (Though I guess I don't really need to do that; I could put whatever I want.)

I am a Software Engineer. I'm licensed by our provincial body and have my P.Eng. and yeah, I still agree with you.

I've been asked why I got my P.Eng as it does nothing for me career wise, but I always have the hope that we move towards a profession that does utilize engineers with proper accreditation and responsibilities where appropriate. I work in Industrial Controls and what my job has me doing does have safety concerns. We fired a student at one point working for us because his attitude towards the work was lackluster and lazy. I see it often enough in programs I'm asked to pick up and fix too.

If Software Engineering wants respect, the profession needs to accept that we're going to piss off a lot of Developers & Architects using the title incorrectly. We still need to develop the proper rigor to take Engineering as a discipline seriously, but we also don't need to apply "Engineers" to every job.

Re: Log4j: The pain just keeps going

#286

Post by kag0 »

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…

is this ML workload an "I trained a model, pickled it, and now we ship that around in production" type situation?

Re: Log4j: The pain just keeps going

#287

Post by stonemetal12 »

kelnos wrote: post #222
stonemetal12 wrote: post #168

Earlier quoted context omitted.

These Log4j issues aren't real hardcore exploits. They wrote a logger that could run arbitrary code, then were surprised when attackers figured out how to run arbitrary code. It isn't a language problem, it is a developer practices problem. Developers code like security isn't a thing then are confused when their programs aren't secure.

> It isn't a language problem, it is a developer practices problem. Developers code like security isn't a thing then are confused when their programs aren't secure. I'd prefer that the "fix" for this isn't "require that millions of developers around the world all change their behavior, and never screw up in the future". Languages can still protect against these sorts of bugs. Effect systems can describe as a part of…

The issue is like SQL Injection. Much like SQL Injection protection the logger needs to separate "active" strings vs attacker controlled "data" strings. It is pretty easy to design boring Java types that solve the issue. The only problem is they didn't. Unless this effects system somehow forces them to not do something dumb, we will end up with a logger that has effects set to "does everything under the sun", and a similar bug.

Re: Log4j: The pain just keeps going

#288

Post by SomeCallMeTim »

kodah wrote: post #157
SomeCallMeTim wrote: post #117

Earlier quoted context omitted.

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

You can't use a technical solution to fix a management problem, no. :)

Re: Log4j: The pain just keeps going

#289

Post by SomeCallMeTim »

taeric wrote: post #170
SomeCallMeTim wrote: post #117

Earlier quoted context omitted.

>"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 don't see how you have really fixed the break much. Especially if you can "push back" and say no to an update, you are just setting yourself up for when the update is even harder to accept. (That is, the further behind on an update you are, the harder to take it. Typically.) And then there is the "I want the fix, but I don't want the added attack vector of features that comes with it."

99% of the time it's a minor update patch that you really should just apply, or Snyk will add a patch to the build to fix the security hole directly.

Honestly it's just not worth worrying about whether a security hole is exploitable when the decision is whether to accept a minor update patch. Just accept the patch PR and move on.

The times you need to do a major update to get a patch fix it's equally important to just make that upgrade, since that means the ancient version you're using is likely out of maintenance and likely is throwing warnings that you're using a deprecated version.

Yes, it's more work to perform a major upgrade. But that doesn't mean it isn't good engineering to keep your tools up to date.

Re: Log4j: The pain just keeps going

#290

Post by SomeCallMeTim »

bastardoperator wrote: post #146
SomeCallMeTim wrote: post #117

Earlier quoted context omitted.

>"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.

True enough, though Snyk will sometimes offer a patch rather than a PR to a new version of the dependency.

The Snyk tools apply to the patch directly to (e.g.) `node_modules` after the latest code has been downloaded.

Post reply on HN