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