Chapter 7. Known Issues

Google Guava versions 11.0 through 24.1 are vulnerable to unbounded memory allocation in the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization). An attacker could exploit applications that use Guava and deserialize untrusted data to cause a denial of service — for more details, see CVE-2018-10237.

To avoid this security vulnerability, we recommend that you:

To make it easier to avoid the earlier (vulnerable) versions of Guava, Fuse 7.7 has configured its Maven Bill of Materials (BOM) files for all containers to select Guava 27 by default. This means that if you incorporate a Fuse BOM into your Maven project (by adding a dependency on the BOM to the dependencyManagement section of your POM file) and then specify a dependency on the Guava artifact without specifying an explicit version, the Guava version will default to the version specified in the BOM, which is version 27 for the Fuse 7.7 BOMs.

But there is at least one common use case involving the Apache Karaf (OSGi) container, where it is not possible to avoid using a vulnerable version of Guava: if your OSGi application uses Guava and Swagger together, you are obliged to use Guava 20, because that is the version required by Swagger. Here we explain why this is the case and how to configure your POM file to revert the earlier (vulnerable) Guava 20 library. First, you need to understand the concept of a double OSGi chain.

Double OSGi chain

Bundles in the OSGi runtime are wired together using package constraints (package name + optional version/range) — imports and exports. Each bundle can have multiple imports and usually those imports wire a given bundle with multiple bundles. For example:

BundleA
+-- BundleB
|   +-- BundleCa
+-- BundleCb

Where BundleA depends on BundleB and BundleCb, while BundleB depends on BundleCa. BundleCa and BundleCb should be the same bundle, if the export the same packages, but due to version (range) constraints, BundleB uses (wires to) a different revision/version of BundleC than BundleA.

Rewriting the preceding diagram to reflect what happens when you include dependencies on both Guava and Swagger in an application:

org.jboss.qe.cxf.rs.swagger-deployment
+-- Guava 27
+-- Swagger 1.5
    +-- reflections 0.9.11
        +-- Guava 20

If you try to deploy this bundle configuration, you get the error, org.osgi.framework.BundleException: Uses constraint violation.

Reverting to Guava 20

If your project uses both Guava and Swagger libraries (directly or indirectly), you should configure the maven-bundle-plugin to use an explicit version range (or no range at all) for the Guava bundle import, as follows:

<Import-Package>
    com.google.common.base;version="[20.0,21.0)",
    com.google.common.collect;version="[20.0,21.0)",
    com.google.common.io;version="[20.0,21.0)"
</Import-Package>

This configuration forces your OSGi application to revert to the (vulnerable) Guava 20 library. It is therefore particularly important to avoid deserializing AtomicDoubleArray instances in this case.

Apache Solr is a popular open source search platform that uses the Apache Lucene search engine. If your application uses a combination of Apache Solr with Apache Lucene (for example, when using the Camel Solr component), it could be affected by this security vulnerability. Please consult the linked security advisory for more details of this vulnerability and the mitigation steps to take.

In Fuse 7.8, if you are running Fuse Online in an offline (disconnected from the internet) environment and you have configured the Fuse Online custom resource (CR) to use a custom Maven repository on your local network, for example:

...
      server:
        features:
          maven:
            append: false
            repositories:
              customRepo1: http://192.0.2.0:8080
...

Then there are particular circumstances where other Maven repositories are consulted, in addition to the specified customRepo1, in spite of the fact that the append: false flag is specified in the CR. For example, this can happen if Fuse Online is configured to use extensions that download Maven dependencies while they are building. Typically, this issue causes longer build times, because the incorrect Maven repositories are consulted before the specified custom Maven repository, which wastes time during the build process.

In Fuse 7.8, if you are attempting to install Fuse Online on OCP 3.11 with the Jaeger add-on enabled (enhanced activity tracking), it is possible you might encounter the following error:

Unknown desc = toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit

This happens because the productised Jaeger container references Dockerhub images, which are out of Red Hat’s control. To work around this issue, you can either wait until rate limit window times out, or disable the Jaeger add-on.

Starting in Fuse 7.7, specifying the JSon Patch as described in step 7 of the procedure Updating specified fields in a resource on a FHIR server does not work, because the value of the JSon Patch is not used by the connector and the error Unable to determine encoding of patch is raised by the integration.

To work around this issue, you can instead open up the settings for JSon Patch in the Data Mapper, as described in step 9.ii, and directly set the values of the fields, op, path, and value in the Data Mapper (see also the screenshots in ENTESB-14237).

In Fuse 7.8, if you create a Karaf custom distribution (for example, based on the Fuse 7.8 Karaf custom quickstart) and then deploy this custom distribution to OpenShift, you might encounter an OSGi import conflict involving javax.xml.bind. This import conflict occurs because the Karaf system bundles export more than one version of the JAXB API package (that is, versions 2.2 and 2.3). Standalone Apache Karaf is not affected by this, because it ensures that the proper versions (both 2.2 and 2.3) of the JAXB packages are available through system bundle (that is, bundle 0). This ensures that when other features (like CXF ones) are installed, those features don’t have to install their own JAXB API bundles, thus preventing the API conflict.

To work around this problem you should add the following line to the POM of your Karaf custom distribution:

<library>mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jaxb-api-2.3/${version.org.apache.servicemix.specs.jaxb};type:=endorsed;export:=true</library>

Where you need to replace ${version.org.apache.servicemix.specs.jaxb} in the above example with the relevant literal version in your POM file, because properties defined in a Maven BOM file are not carried over to the POM file. To discover the relevant value of the version.org.apache.servicemix.specs.jaxb property, start with the fuse-karaf-bom BOM file referenced in the dependencyManagement section of your POM and follow the chain of recursively imported BOM files, until you find the one that contains the definition of version.org.apache.servicemix.specs.jaxb. For example, for Fuse 7.8 you can find the value of the version.org.apache.servicemix.specs.jaxb property in the https://maven.repository.redhat.com/ga/org/jboss/fuse/jboss-fuse-parent/7.8.0.fuse-780038-redhat-00001/jboss-fuse-parent-7.8.0.fuse-780038-redhat-00001.pom BOM file.

Starting in Fuse 7.5.0, some of the Spring Boot 2 quickstarts (generated either from Maven archetypes or quickstart templates) fail to build and deploy to OpenShift. The following Spring Boot 2 Maven archetypes are affected:

And the following Spring Boot 2 templates:

To work around this issue, after generating a Maven project for one of these quickstarts, edit the project’s Maven pom.xml file to add the following dependency:

<dependency>
  <groupId>org.assertj</groupId>
  <artifactId>assertj-core</artifactId>
  <version>2.4.1</version>
  <scope>test</scope>
</dependency>

Starting in the Fuse 7.0 GA release, in the Apache Karaf container the start level of hot deployed bundles is 80 by default. This can cause problems for the hot deployed bundles, because there are many system bundles and features that have the same start level. To work around this problem and ensure that hot deployed bundles start reliably, edit the etc/org.apache.felix.fileinstall-deploy.cfg file and change the felix.fileinstall.start.level setting as follows:

felix.fileinstall.start.level = 90

The framework-security OSGi feature must be installed using the --no-auto-refresh option, otherwise this feature will shut down the Apache Karaf container. For example:

feature:install -v --no-auto-refresh framework-security

In Fuse 7.7, there is an error in the README instructions for the new SOAP to Rest quickstart (camel-soap-rest-bridge). In the Prerequisites section, the command for installing the RH SSO EAP Adapter is given as:

./bin/jboss-cli.sh --file=bin/adapter-elytron-install-offline.cli

But the correct command is actually:

./bin/jboss-cli.sh --file=bin/adapter-elytron-install-offline.cli -Dserver.config=standalone-full.xml

Due to the removal of the JMX RMI Connector feature from Fuse 7.8, the Camel Debugger does not work when you right-click a project and select the Debug as > Local Camel Context option. To workaround the issue, follow these steps: