I could see there is a dependency with log4j and log4j-core-2.13.3.jar is embedded in corda.jar. Is there any update available or how can we fix the log4j related vulnerability
This page provides updates on all major alerts, fixes and forthcoming patch releases. Check the top of the page for the most urgent alerts.
Related
This is regarding the CVE-2022-42889 vulnerability. From the below documentation link its mentioned that
"However we are actively working on upgrading the vulnerable dependency version to non-vulnerable version to reduce the unnecessary noise made by the Software Composition Analysis scanners. Customers may apply the security update once it is available. "
https://docs.wso2.com/display/Security/CVE-2022-42889
We wanted to know if there is any ETA for the vulnerable jars to be removed from WSO2 products.
Thanks,
Navaneeth
Security vulnerability. security tools are reporting the jar as vulnerable.
This is an ongoing effort the WSO2 API Manager versions and the update will be released within next couple of weeks.
I am provided with Corda Enterprise artifacts to test our solution against it. We don't yet have a enterprise support, this is still a non tech work in a process, so I am asking here a tech question:
After downloading all the developer pack artifacts from Corda Enterprise 4.5 and putting them in my local maven repository I continue to get the following error Could not resolve com.r3.libs:r3-libs-obfuscator:1.0.
I spent many hours trying to find a solution but I could not find even a clue about this particular jar file. There is nothing at all related to it in the Internet.
I searched the slack channel of Corda and there are at least 5 people facing the same issue that I do, but nobody seems to have found the solution to this. Some people tell that his can be related to corda-tools-config-obfuscator-4.5-GA.jar somehow, but I don't think so, as this jar is right there in my repository and anyways the name and the package of the missing jar is different.
The only way to build cordapp was to exclude this dependency from any Corda dependency that relays on this one. One of such a dependency is corda-node btw, but this seems to be a wrong solution as I exclude a transient dependency from artifacts that I don't own, and I have no clue on when this excluded package might be needed to corda-node dependency and how exactly will it fail in absence of this one.
So please can someone from Corda Enterprise team give us a hint on what this jar is and where can we find it. I have a feeling that someone just forgot to put it in the developer pack of Corda Enterprise artifacts...
It looks like it is a missing dev pack library issue, basically.
The de-obfuscation code is now common across CENM and Corda and is hence a separate library.
You can find them here: https://software.r3.com/artifactory/webapp/#/artifacts/browse/tree/General/r3-tools-dev/com/r3/libs/r3-libs-obfuscator/1.0-SNAPSHOT/r3-libs-obfuscator-1.0-20200409.080322-2.jar
You might need to contact your account manager to get it if you currently don't have access to it.
I developed an app that'll stream a rtmp video. Before I used VitamioBundle-master. I upload my app in play store it shows some warning message for upgrading my app that has to use vitamio latest version. I download it from the link shown in that alert message. Now I develop the app using vitamio 5.0.2 downloaded from the link https://www.vitamio.org/en/Download/. Once I upload the app play store shows the same alert message
Security alert
Your app utilizes a version of Vitamio, a multimedia library used for playing various types of media files, containing a security vulnerability.
Please upgrade your app(s) as soon as possible and increment the version number of the upgraded APK. Beginning 14 March 2016, Google Play will block publishing of any new apps or updates that use pre-5.0 versions of Vitamio.
The vulnerability was addressed in Vitamio v5.0. The latest versions of Vitamio can be downloaded on the Vitamio website. You can confirm your Vitamio version by checking if the SDK includes libs/armeabi-v7a/libvinit.so or libs/armeabi/libvinit.so. If either file is present, the SDK needs to be upgraded. For help upgrading, see the Vitamio support documentation. If you’re using a 3rd party library that bundles Vitamio, please notify the 3rd party and work with them to address this.
To confirm you’ve upgraded correctly, submit the updated version to the Developer Console and check back after five hours. If the app hasn’t been correctly upgraded, we will display a warning.
The vulnerability is due to the Vitamio SDK containing world-writable code. For more information about the vulnerability, please see this NowSecure blog post. For other technical questions, you can post to Stack Overflow and use the tags “android-security” and “vitamio.”
While these specific issues may not affect every app that uses Vitamio, it’s best to stay up to date on all security patches. Apps with vulnerabilities that expose users to risk of compromise may be considered in violation of our Malicious Behavior policy and section 4.4 of the Developer Distribution Agreement.
Apps must also comply with the Developer Distribution Agreement and Developer Program Policies. If you feel we have sent this warning in error, contact our policy support team through the Google Play Developer Help Center.
I gone through several solutions mentioned in different tutorial but not yet get a clear idea. Can anyone tell me the step by step procedure for updating my vitamio sdk version, or else is there any other lib for streaming rtmp video in my Android app?
Unfortunately, Vitamio 5.0.2 added back the old libvinit.so file, so it gets flagged as an old version of Vitamio. You can just delete libvinit.so and it should work.
I am trying to implement code where I can send and receive the SOAP messages to IBM MQ. As of my knowledge jar file are required for my code to work, but could not find any place where either I can download the files or can do whole setup of WebSphere 6.0
Do anyone have any idea how can I get it ?
Please be aware that grabbing the jar files from an MQ Server or other installation is not supported by IBM and never has been. However, because it is one of the most commonly used methods to install the MQ client for Java or JMS and fairly common in Java developer culture, IBM has provided a Java-only install option. Please see the Redistributable Clients page in the Knowledge Center for details.
As the name suggests, this install provides an MQ Client package that can be redistributed with independently developed MQ applications. While that is helpful, the main reason IBM provides it is to provide a lightweight install package that...
Contains the correct and complete set of jar files as packaged by IBM.
Is intact and verifiable against a known specification and inventory.
Can reliably be expected to perform as per the documentation set for that version.
Contains all of IBM's diagnostic utilities both in the compiled binaries and in the Java classes.
Contains additional utilities such as GSKit for managing certificates.
Can be patched using IBM's standard Fix Pack install media so that integrity of the installed classes and libraries is preserved.
When using IBM's install media and procedure, the result is far more stable but int he event something goes wrong, the presence of the diagnostic utilities and conformance to a standard install procedure can dramatically reduce outage durations.
Also, there are occasional instances in which a customer with full support entitlements is told that their non-standard installation is not supported and they need to correct it before continuing the PMR. Though this doesn't happen often, in most cases the problem is resolved when the MQ client is installed according to spec. When that doesn't fix it, at least diagnostics can proceed at a faster pace.
The link above has all the details, including links to the client downloads, and is highly recommended reading. You can also go directly to Fix Central for the downloads. Fix Central offers all supported MQ client versions and the relocatable clients come in v8.0 and up. In the download list, look for the "All Java" package.
As Tim noted, mixing client and server versions is supported, provided both client and server are currently in service. Generally you want to develop against the latest version of MQ client because it has the most recent client-side features and will have the longest service life before a version upgrade is required.
Assuming you're on a Unix platform for your queue manager, the client will be found at:
/opt/mqm/java/lib
However, all MQ clients are compatible with all queue manager versions. I strongly recommend you use a client which is still supported, which means 7.1, 7.5, 8.0, or 9.0 at time of writing. These are freely downloadable from the SupportPac website.
The SupportPacs of interest are those starting 'MQC'. SupportPac MQC8 for example contains the MQ V8.0 client.
Thanks everyone. Just an update to the above answer. In my case I have asked the WebSphere administrator for providing me the lib folders which contains all the required MQ jar files.
I have asked him to provide following files from the C:\Program Files (x86)\IBM\WebSphere MQ\Java\lib\ folders:
* com.ibm.mq.jar
* connector.jar
* com.ibm.mq.jmqi.jar
* com.ibm.mq.headers.jar
* com.ibm.mq.commonservices.jar
If a plone version is upgraded, should security patches be removed?
Hypothetical example:
Plone X.4.4 is running with Security Patch-XYZ from May 4th 2015
Plone is upgraded to X.4.5 which is released after Security Patch-XYZ
I assume the security patches are included in the next release. Should they be removed from our build?
Thanks.
In general, yes. There is one exception to date: the 20151006 hotfix, which is only partially included in Plone 4.3.9. See the hotfix notes for detail. The background is that this hotfix applies some very aggressive automated CSRF defenses that are not appropriate for all situations.
When in doubt, check the hotfix page or the full hotfix list.
In addition to Steve's answer: it is advised to remove the hotfixes from your buildout when the patches are included in core Plone, but when you forget this no breakage is expected. In most cases the worst that will happen is that you get a warning in the logs that a hotfix could not be cleanly applied.