Peter Palaga created CXF-9261:
---------------------------------
Summary: Decouple adding bc-fips dependency from FIPS dependent
behavior at runtime
Key: CXF-9261
URL: https://issues.apache.org/jira/browse/CXF-9261
Project: CXF
Issue Type: Bug
Reporter: Peter Palaga
PR [#1893|https://github.com/apache/cxf/pull/1893] has added a Maven profile
called `fips`.
It is activated via `-Dfips.enabled` and adds `org.bouncycastle:bc-fips`
dependency.
The same PR added a few changes of behavior at runtime, that are also enabled
by `fips.enabled` system property.
This enables testing the FIPS behavior with a specific FIPS-compliant security
provider and it works well for folks wanting `org.bouncycastle:bc-fips`.
However, testing with alternative FIPS-compliant providers becomes hard or only
possible with dirty workarounds. Specifically, FIPS testing with an alternative
FIPS-compliant provider on Quarkus CXF gets hard.
It is because Quarkus builds the test app, (which includes dependency
resolution) from within its JUnit extension. That JUnit extension is run inside
the JVM forked by Maven surefire/failsafe plugins. To enable the runtime FIPS
behavior during the test, there is no other way to pass `-Dfips.enabled` to
that JVM than via surefire/failsafe failsafe config. Because the dependency
resolution happens inside that JVM, it also adds the `org.bouncycastle:bc-fips`
dependency. So it is not possible to build and run the test app without
`org.bouncycastle:bc-fips` dependency but with FIPS runtime behavior.
I think similar scenario is possible with plain CXF.
To solve the sketched problem I would like to propose the following:
* Do not assume `org.bouncycastle:bc-fips` is the default security provider
when FIPS is enabled at runtime.
* Decouple the activation of the FIPS runtime behavior from adding the
`org.bouncycastle:bc-fips` dependency by renaming the fips profile activation
property to e.g. `bc-fips.enabled`.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
