Jedis(URI, JedisClientConfig) drops SslOptions, widening TLS trust to JVM defaults

Problem

Jedis(URI, JedisClientConfig) silently drops SslOptions from the supplied config, so a client configured with a pinned truststore / mTLS keystore over SslOptions connects with JVM-default trust instead.

The constructor rebuilds a fresh config field-by-field to overlay the URI-derived user/password/database/protocol/ssl. It carries the legacy TLS trio but not SslOptions:

.ssl(JedisURIHelper.isRedisSSLScheme(uri)).sslSocketFactory(effective.getSslSocketFactory())
.sslParameters(effective.getSslParameters()).hostnameVerifier(effective.getHostnameVerifier())
.build());

SslOptions is the documented TLS entry point (truststore, keystore/mTLS, SslVerifyMode); the legacy ssl* setters are deprecated in its favour since 7.4.2 and it takes precedence. Every other copy path preserves it — DefaultJedisClientConfig.copyConfig and Builder.from both call sslOptions(...) — and the sibling Jedis(HostAndPort, JedisClientConfig) hands the config straight to Connection, so SslOptions is honoured there. Only the URI constructor drops it.

When it is dropped, DefaultJedisSocketFactory.createSslSocket sees sslOptions == null and falls through to SSLSocketFactory.getDefault(): the trust anchor widens from the operator's pinned CA to the whole JVM cacerts bundle, the configured client certificate is never presented, and the SslVerifyMode is lost — a silent weakening of the intended TLS posture with no warning.

Minimal reproducible example

Against a plaintext server, a client that honours SslOptions attempts a TLS handshake (and fails); one that drops it connects in the clear. The two constructors disagree:

SslOptions sslOptions = SslOptions.builder().sslVerifyMode(SslVerifyMode.INSECURE).build();
JedisClientConfig config = DefaultJedisClientConfig.builder().sslOptions(sslOptions).build();

// honours SslOptions -> attempts TLS -> throws against a plaintext endpoint
new Jedis(new HostAndPort("localhost", port), config);

// drops SslOptions -> connects in plaintext, no TLS attempted
new Jedis(URI.create("redis://localhost:" + port), config);

Fix

Add .sslOptions(effective.getSslOptions()) to the constructor's builder chain, next to the ssl* fields it already copies. PR to follow.