Comment by imtringued
3 months ago
None of this makes any sense. There is no waiting. You just do it. In no universe can you justify using a vulnerable log4j version. You force gradle to use the patched log4j and be done with it.
Five years has nothing to do with Java. It means nobody cares about security in the first place. Outsourcing such a trivial security problem to Microsoft is just another nail in the coffin. "I have no capacity to develop secure software, better make myself dependent on someone who can".
I'm not saying that making an exception is the correct course of action. But it isn't my call to make so it kind of doesn't matter what I think in this case.
What I'm trying to point out is that I've never known this kind of security vulnerability to be quite such a hassle to eradicate when working on the .NET stack. Because the "batteries included" nature of .NET just makes it easier. On Java the supply chain tends to be more unwieldy. Which seems to engender both increased maintenance hassle and a greater tendency toward normalization of deviance. Perhaps as a way to try to sand the sharp corners off of the maintenance hassle.
> There is no waiting. You just do it. In no universe can you justify using a vulnerable log4j version.
I agree.
We had been doing interop with a Java process from C# to access some document processing functionality during the log4j incident. The library we were using depended on log4j and had a clear resolution at the time, but there was a big perception problem in our client base (i.e., non-technical people that we must suffer in order to continue doing business).
Our solution to the resulting paranoia was to remove Java from our stack altogether. It was a big pain in the ass to find an alternative, but it was definitely worth it from a customer service perspective. Our clients were very happy with this approach and it saved us from a lot of messy meetings that other vendors were sucked into.