Live data from Hacker News

CISA Director on Log4j Vulnerability

cisa.gov

81–85 of 85 posts

Re: CISA Director on Log4j Vulnerability

#81

Governments should 1. Step up and shoulder part of the finding for maintainers 2. Close their double quotes on press releases

One of Sovereigntechfunds goal is to support maintainers of critical open source infrastructure with public money. https://sovereigntechfund.de/en

Germany for now, but plans are to expand "up" to Europe as far as I know (we are all in the same boat, aren't we)

Re: CISA Director on Log4j Vulnerability

#82
post #17

Earlier quoted context omitted.

No. The stakeholders are busy patching their shit. Pulling folks into meetings shouldn't be the priority when teams around the world in virtually every tech organizations are in firefighting mode. This type of a call would likely be focused on assessing current state at that point.

The people that would be in that meeting are not the individuals actually patching servers.

No, they are managing the teams patching things and helping with prioritization.

If the stakeholders participating in the call on Monday are not the people working on patching, managing, or prioritizing, then having the call earlier than that is pointless, because those stakeholders are too removed from the situation, and getting that information will detract from getting work done.

It's pretty simple really, having a status or coordination call while the work is being done is roughly analogous to a photo-op by a politician during an emergency. It looks good for the voters, but it takes away resources from the folks who are actually doing the work.

Re: CISA Director on Log4j Vulnerability

#83
post #46

Earlier quoted context omitted.

It does matter. To quote the original parent: "do I need to worry about this as a frontend web developer?" A frontend web developer doesn't manage nginx, nor ES. The backend should be patched. It is not safe to just mitigate the bug by using code in the frontend.

As a frontend dev shouldn't you worry about your clients, rather than the boundaries of your organisation ? Harass whomever is putting the log4j dependency in the backend until they patch, don't expect them to know by default.

Sure, but it's not your job to know every single vulnerability that can be in your backend.

Re: CISA Director on Log4j Vulnerability

#84
post #35

Earlier quoted context omitted.

The JVM running with a security policy can do this. It's pretty rarely done though.

The idea of having different declarative security realms is fine but it's not what the Java Security Manager is. The Java Security Manager is an API that allows to intercept and run codes, so devs use it as a Trojan Horse to patch code instead of fixing the root of the issue. The Java Security Manager should die.

> The idea of having different declarative security realms is fine but it's not what the Java Security Manager is.

But.. it is?

The JVM tracks where bytecode was loaded from, and then you can define a policy to limit what that code can do.

Here's an example giving read-only access to /etc

https://access.redhat.com/documentation/en-us/red_hat_jboss_...

Re: CISA Director on Log4j Vulnerability

#85

Earlier quoted context omitted.

This reminds me a lot of audiophile woo as well. It seems like this sort of grift could be applied to just about anything where the technology is indistinguishable from magic.

Got any examples of audiophile scams?

https://en.wikipedia.org/wiki/Magic_Alex
Post reply on HN