feat(gax-httpjson): Add Post Quantum Cryptography (PQC) Support by default via Conscrypt

[lqiu96]

No description provided.

[gemini-code-assist]

Code Review

This pull request introduces Post-Quantum Cryptography (PQC) TLS negotiation for HTTP/JSON clients by integrating Conscrypt as a security provider and adding corresponding integration tests. The reviewer feedback focuses on improving the robustness and architecture of this implementation. Specifically, the reviewer recommends removing the undesirable coupling from the core HTTP module to the transport-specific module by defining the PQC groups locally. Additionally, the reviewer suggests wrapping the Conscrypt named groups configuration in a defensive try-catch block and separating the builder creation from the build calls to prevent genuine configuration or mTLS errors from being incorrectly swallowed as Conscrypt loading failures.

[gemini-code-assist]

This import is unnecessary and introduces an undesirable coupling from the core HTTP module (google-cloud-core-http) to the transport-specific module (gax-httpjson). We can remove this import by defining the PQC groups array locally within this class.

References

1. Avoid inverting layering by making lower-level channel implementations depend on higher-level RPC wrappers. If code is duplicated and needs to be shared, move it to a separate helper/utility class.

[lqiu96]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces Post-Quantum Cryptography (PQC) TLS negotiation support for HTTP/JSON clients by registering Conscrypt as the security provider and configuring default PQC named groups. The feedback suggests utilizing lazy initialization and caching for the Conscrypt security provider in both InstantiatingHttpJsonChannelProvider and HttpTransportOptions to prevent the performance and memory overhead of instantiating a new provider on every transport creation.

[gemini-code-assist]

Prefer lazy initialization and caching for resource-intensive objects like the Conscrypt security provider. Creating a new Provider instance on every transport creation can lead to significant performance overhead and high memory usage.

We can introduce a static lazy holder class to cache the Conscrypt provider instance safely, ensuring it is only initialized once and does not cause class-loading issues if Conscrypt is not present on the classpath.

    private static final String[] PQC_GROUPS =
        new String[] {"X25519MLKEM768", "SecP256r1MLKEM768", "X25519"};
    private static final HttpTransportFactory INSTANCE = new DefaultHttpTransportFactory();

    private static class ConscryptProviderHolder {
      private static final java.security.Provider INSTANCE = createProvider();

      private static java.security.Provider createProvider() {
        try {
          return Conscrypt.newProvider();
        } catch (Throwable t) {
          LOG.log(
              Level.FINE,
              "Conscrypt native libraries not available. Falling back to JDK TLS.",
              t);
          return null;
        }
      }
    }

References

1. Prefer lazy initialization over eager initialization for resource-intensive objects (such as CharsetEncoder) if they are not guaranteed to be used in all execution paths, to avoid unnecessary performance and memory overhead.

[blakeli0]

Are there known checked exceptions? If not, catching Exception is fine but catching Throwable might hide larger problems. e.g. Even if a version mismatch is ignored here, it might blow up in other places.

[lqiu96]

It doesn't throw any CheckExceptions. I'll change this so that it catches Exceptions instead. Online suggests the possibility of wrapped SSLSockets or proxied ones failing the Conscrypt check, but that seems to throw an Exception instead.

If there is a version mismatch of a JNI issue, that should be caught in the Conscrypt initializaiton logic and would be caught by the conscryptProvider == null check above.

[blakeli0]

where Conscrypt is unsupported

What error would we run into?

[lqiu96]

I'm not too sure. I think it's a linkage error but i'm not too familiar with native API logic as to which error message is thrown

[lqiu96]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces Post-Quantum Cryptography (PQC) support for HTTP/JSON transports by integrating Conscrypt and configuring hybrid key exchange groups (e.g., X25519MLKEM768). Feedback on the changes highlights several critical improvements: first, createHttpTransport() should continue to return null when mTLS is disabled to preserve connection pooling and prevent socket exhaustion; second, HttpJsonTransportUtils should catch Throwable instead of Exception to gracefully handle potential native linkage errors from Conscrypt; and finally, the integration tests should restore the global default SSLContext after execution to avoid test pollution across the JVM.

[lqiu96]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces Post-Quantum Cryptography (PQC) support for HTTP/JSON (REST) clients by integrating Conscrypt as the default security provider and configuring hybrid key exchange groups. Key changes include the addition of the Conscrypt dependency, the creation of HttpJsonTransportUtils to configure the transport builders, and integration tests to verify the TLS negotiation. The review feedback highlights critical improvements: ensuring Conscrypt is preserved when mTLS is active, exposing the Conscrypt provider instance, catching LinkageError to handle older Conscrypt versions, and using reflection in tests to configure named groups on standard JDK sockets to prevent future test failures on newer JDKs.

[gemini-code-assist]

When mutual TLS (mTLS) is enabled, configureMtls calls builder.trustCertificates(...) which internally creates an SSLContext using the default system provider (typically SunJSSE) rather than the configured Conscrypt provider. As a result, the transport will not use Conscrypt or PQC when mTLS is active. To fix this, we should construct the SSLContext using the Conscrypt provider when mTLS is enabled.

    if (mtlsProvider != null && certificateBasedAccess.useMtlsClientCertificate()) {
      KeyStore mtlsKeyStore = mtlsProvider.getKeyStore();
      if (mtlsKeyStore != null) {
        java.security.Provider conscryptProvider = HttpJsonTransportUtils.getConscryptProvider();
        if (conscryptProvider != null) {
          javax.net.ssl.SSLContext sslContext =
              javax.net.ssl.SSLContext.getInstance("TLS", conscryptProvider);
          com.google.api.client.util.SslUtils.initSslContext(
              sslContext,
              null,
              com.google.api.client.util.SslUtils.getPkixTrustManagerFactory(),
              mtlsKeyStore,
              com.google.api.client.util.SslUtils.getDefaultKeyManagerFactory(),
              "");
          builder.setSslSocketFactory(sslContext.getSocketFactory());
        } else {
          builder.trustCertificates(null, mtlsKeyStore, "");
        }
      }
    }

[gemini-code-assist]

Expose the Conscrypt provider instance so that other components (such as InstantiatingHttpJsonChannelProvider during mTLS configuration) can reuse it to initialize their custom SSLContexts.

Suggested change

	}
	}
	/**
	* Returns the Conscrypt {@link Provider} instance, or {@code null} if Conscrypt is unavailable.
	*
	* @return the Conscrypt provider or null
	*/
	public static Provider getConscryptProvider() {
	return ConscryptProviderHolder.INSTANCE;
	}

[gemini-code-assist]

If an older or incompatible version of Conscrypt is present on the classpath, calling Conscrypt.setNamedGroups might throw a NoSuchMethodError or other LinkageError (which are subclasses of Error, not Exception). Catching LinkageError along with Exception ensures that the application won't crash and can safely fall back to Conscrypt's default TLS groups.

Suggested change

	} catch (Exception e) {
	} catch (Exception | LinkageError e) {

[gemini-code-assist]

In testHttpJsonPqc_withExplicitSecurityProviderNoPqcGroups, the transport is explicitly configured to use the SunJSSE provider. Because of this, the socket will not be a Conscrypt socket, and Conscrypt.isConscrypt(socket) will return false. Consequently, the named groups are never restricted to classical curves on SunJSSE. On future JDK versions (e.g., JDK 27+) where SunJSSE enables PQC by default, this test will negotiate PQC and fail. We should use reflection to set the named groups on the standard JDK socket if supported.

            .setSslSocketConfigurator(
                socket -> {
                  if (Conscrypt.isConscrypt(socket)) {
                    Conscrypt.setNamedGroups(socket, new String[] {"X25519", "SecP256r1"});
                  } else {
                    try {
                      javax.net.ssl.SSLParameters params = socket.getSSLParameters();
                      java.lang.reflect.Method setNamedGroupsMethod =
                          javax.net.ssl.SSLParameters.class.getMethod("setNamedGroups", String[].class);
                      setNamedGroupsMethod.invoke(params, (Object) new String[] {"X25519", "SecP256r1"});
                      socket.setSSLParameters(params);
                    } catch (Exception e) {
                      // Ignore if setNamedGroups is not supported on this JDK version
                    }
                  }
                })

[sonarqubecloud]

Quality Gate failed for 'gapic-generator-java-root'

Failed conditions
61.5% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

[sonarqubecloud]

Quality Gate failed for 'gapic-generator-java-root'

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud