For the newest version of PDI 9.3, it still uses jetty 9.4.18. There are several security issue of jetty and no workaround for some of them, such as CVE-2022-2047, CVE-2022-2048. And if replaces jetty*.jar to newer version such as 9.4.48, PDI will work not properly.
So how to resolve the security issue of jetty in PDI(kettle)?
Thank you.
Related
We are trying to upgrade Rundeck version from 3.0.27 to the latest version (3.4.7)
We got below questions,
What is the approach to upgrade from 3.0.xxxx to 3.4.7? Could we do a direct upgrade or otherwise, if we have to run through multiple intermediary versions, what are those?
Does upgrading from 3.0.xxx to 3.4.7 fix the log4j vulnerability?
Please help to clarify above.
Thanks
Due to the big gap between 3.0.X and 3.4.X (and the upcoming 4.0.X) the best way to upgrade your instance is to create a fresh 3.4/4.0 instance and then import your projects and keys (exported previously), as a tip, try this on a non-prod environment first.
Rundeck 3.0.x uses log4j 1, so, even if the vulnerability doesn't affect explicitly the log4j 1.x EOL was in 2015 and isn't supported anymore, so, it's important to move to the latest version (Rundeck 3.4.10 at this moment).
what would be the compatible weblogic versions for the log-2.17.1. any Reference link is useful.
part of my research nowhere i found related solutions in the official sites
It would be more the java version that weblogic runs on. If it supports java 8 then you would be able to use log4j 2.17.1. I think weblogic 12.1.3 onwards supports java 8.
https://javaserverfaces.java.net/nonav/2.2/releasenotes.html lists two diverging version branches of JSF2.2 where, strangely, 2.2.8-xx seems to be more recent than 2.2.9 and above.
Some bugs are fixed only in 2.2.9 (https://github.com/javaserverfaces/mojarra/issues/3384), some only in 2.2.8-xx (https://github.com/javaserverfaces/mojarra/issues/4111) and some in both versions (https://github.com/javaserverfaces/mojarra/issues/3133).
Whats the reason behind this and which branch should I use in production? Both seem to contain important bugfixes.
I could not find anything about this with google. Maybe the mojarra guys could add some information to the release notes.
Mojarra 2.2.8-xx releases are built specifically for Oracle WebLogic 12c with handpicked bugfixes from newer releases backported every time. WebLogic has namely a bug in its integrated Weld version which made it incompatible with Mojarra 2.2.9 and newer where the fix for issue 3345 was introduced.
If you aren't using WebLogic 12c, then just ignore the 2.2.8-xx releases altogether and pick the newest 2.2.x which is as of today 2.2.14. If you're however using WebLogic 12c, then you should actually focus on obtaining a maintenance pack from Oracle WebLogic support. It'll bundle the newer Mojarra 2.2.8-xx version.
As reference: I'm a Mojarra committer.
Recently we upgraded to elastic 5.0. The java client in Elastic 5.0 has a hard dependency on log4j 2.6. Storm server (version 1.0.2) on the other hand uses an older version log4J and both are hard wired dependency. The following is the error we get when trying to deploy to the server and i can see that 'PreBuiltTransportClient' is not able to instantiate.
java.lang.NoSuchMethodError: org.apache.logging.log4j.Logger.info(Ljava/lang/String;Ljava/lang/Object;)V
I have raised the issue with Elastic and they have acknowledged the issue and mentioned that they are working on a true client that has lesser dependencies.
Any workarounds or suggestions to get around this for the timebeing?
I found a solution for this and it is working now. Here is what i did,
Storm loads the log4j files using a python script from a specified folder under /lib. The latest version of storm uses log4j 2.1
I copied the log4j 2.6.2 files in to that folder.
Now when I deployed my toplogy, storm started using the log4j2.6.2 in the CLASSPATH.
Elastic client got what it needed and it started working.
Until the light weight Elastic Client is released we will continue to use this workaround.
In my web application I am using apache logging log4j. When I was working jboss as 7.0, logging was working well.
But when i switched to Jboss 7.1 logging is not working. Can somebody let me know what has been changed?
By default in 7.1 logging dependencies are added to each deployment. This works for most people, but if you're using your own log4j configuration this will not work for you in 7.1.1 and lower. You need to exclude the servers log4j dependency.
Note: In 7.2.x this will just work and you can remove the jboss-deployment-structure.xml and the dependency.