Closed michalvavrik closed 2 weeks ago
Quarkus CI
This is the status report for running Quarkus CI
on commit da0a2cd9b254b670117d58c4fb7cbc0ef0b12960.
:white_check_mark: The latest workflow run for the pull request has completed successfully.
It should be safe to merge provided you have a look at the other checks in the summary.
You can consult the Develocity build scans.
fixes: #40659
When run on RHEL8 with Open JDK 17 with BCFIPS provider the SecureRandom strong algorithm is
NativePRNGBlocking:SUN,DRBG:SUN
, algorithms that are not available. Keycloak works around that by just initializing default SecureRandom with known strong algorithms (PKCS11:SunPKCS11-NSS-FIPS) and removing them, but that means that when Vert.x loads keystores during the HTTP Server startup (when users can't provide their fixes, before app starts) andorg.bouncycastle.jcajce.provider.BouncyCastleFipsProvider#getCoreSecureRandom
is invoked whilegetInstanceStrong
throws exception, it leads to initializingorg.bouncycastle.jcajce.provider.BouncyCastleFipsProvider.CoreSecureRandom#CoreSecureRandom
withsun.security.provider.SecureRandom()
and following exception is thrownBouncyCastleFipsProvider$CoreSecureRandom (in unnamed module @0x621a387f) cannot access class sun.security.provider.SecureRandom
.I've tried both using reflection to invoke
org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider#getDefaultSecureRandom
and initialize initialize SecureRandom instance via Java API, but BCFIPS require this strong algorithm later as well. I think we need to keep it in place.My thinking (AKA selected code lines from KC) is that if
NoSuchAlgorithmException
is thrown, that won't change until user code is run on app startup (extensions could do something sooner). Which is too late, and if they want to change the strong algorithm, they can change what we set as well.Tested only in JVM as native mode is not working https://github.com/quarkusio/quarkus/issues/37500.