ppalaga commented on PR #3638: URL: https://github.com/apache/cxf/pull/3638#issuecomment-6466196029
> > * -Dbc-fips.enabled now puts the jar on the classpath but doesn’t register it. Nothing in the codebase calls Security.addProvider for BCFIPS any more, so the profile adds bc-fips without it ever being used unless the JVM’s java.security lists it. > > That's a good point, thanks! I thought the service provider mechanism takes care for it once bc-fips is in the class path, which it really does not. Let me put back the the code loading the `org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider` class in `CryptoUtils`, but make it activated via `bc-fips.enabled` rather than `fips.enabled`. I did it differently in a0caec3: now fips.security.provider must be set when fips.enabled is true. Also checking the validity if the supplied provider names is more strict. For bc-fips all is done from Maven via bc-fips.enabled=true > > The profile also sets org.apache.xml.security.securerandom.algorithm=PKCS11, which already assumes a JDK set up for FIPS, so BCFIPS was only ever a low-priority fallback and the real impact is small. > > Yeah, that follows from the above. By fixing `CryptoUtils`, it will be solved for testing with `bc-fips`, but you are right, `org.apache.xml.security.securerandom.algorithm` should be set for testing with alternative FIPS providers too. So I am perhaps going to add a profile activated through `fips.enabled` that will set `org.apache.xml.security.securerandom.algorithm` but it will not add any dependency. There are two profiles now. I hope that's acceptable like that? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
