dakirily commented on code in PR #181:
URL: https://github.com/apache/qpid-broker-j/pull/181#discussion_r4248190678
##########
broker-core/src/main/java/org/apache/qpid/server/transport/network/security/ssl/SSLUtil.java:
##########
@@ -92,108 +111,25 @@ public class SSLUtil
private static final Logger LOGGER =
LoggerFactory.getLogger(SSLUtil.class);
private static final Integer DNS_NAME_TYPE = 2;
- private static final String[] TLS_PROTOCOL_PREFERENCES = new
String[]{"TLSv1.3", "TLSv1.2", "TLSv1.1", "TLS", "TLSv1"};
-
-
- private static final Constructor<?> CONSTRUCTOR;
- private static final Method GENERATE_METHOD;
- private static final Method GET_PRIVATE_KEY_METHOD;
- private static final Method GET_SELF_CERTIFICATE_METHOD;
- private static final Constructor<?> X500_NAME_CONSTRUCTOR;
- private static final Constructor<?> DNS_NAME_CONSTRUCTOR;
- private static final Constructor<?> IP_ADDR_NAME_CONSTRUCTOR;
- private static final Constructor<?> GENERAL_NAMES_CONSTRUCTOR;
- private static final Constructor<?> GENERAL_NAME_CONSTRUCTOR;
- private static final Method ADD_NAME_TO_NAMES_METHOD;
- private static final Constructor<?> ALT_NAMES_CONSTRUCTOR;
- private static final Constructor<?> CERTIFICATE_EXTENSIONS_CONSTRUCTOR;
- private static final Method SET_EXTENSION_METHOD;
- private static final Method EXTENSION_GET_NAME_METHOD;
- private static final boolean CAN_GENERATE_CERTS;
+ private static final String[] TLS_PROTOCOL_PREFERENCES = new String[] {
"TLSv1.3", "TLSv1.2", "TLSv1.1", "TLS", "TLSv1" };
+ private static final Pattern DNS_NAME_PATTERN =
Pattern.compile("[\\w&&[^\\d]][\\w\\d.-]*");
+
+ private static final Provider PROVIDER = new BouncyCastleProvider();
Review Comment:
@ikshwaks The original failure came from reflective access to
sun.security.tools.keytool.CertAndKeyGen and related internal classes, which
Java 17’s module restrictions blocked. PR #181 replaced those calls with Bouncy
Castle’s public APIs.
Your understanding of provider selection is correct: the explicit provider
is used for certificate conversion, while key generation and signing already
rely on JCA provider selection. The Java 17 fix does not inherently require an
explicit BC provider for conversion, and the standard certificate-generation
path works without it.
A small PR removing both .setProvider(PROVIDER) and the static
BouncyCastleProvider instance looks reasonable, with regression coverage for
certificate generation and reloading. Removing the static instance is important
for addressing the initialization failure you reported. However, mixing
ordinary BC and BC-FIPS libraries can cause further linkage errors, so the
dependency configuration also needs attention.
There is already related work under
[QPID-8773](https://issues.apache.org/jira/browse/QPID-8773), “Support for FIPS
140 compliance using Bouncy Castle FIPS (bc-fips),” and an associated
[mailing-list
discussion](https://lists.apache.org/thread.html/25w5rbxjh6tmlw1kn5j31t19qwv5sqff).
Please coordinate with Partha Sarathy Maripini through that JIRA or
mailing-list thread. That should help align the dependency requirements and
distinguish this focused compatibility fix from the broader FIPS-support work.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
