Should default trustManagers be based on SSLContext?

[guus]

In this snippet of org.jivesoftware.smack.ConnectionConfiguration#getSmackTlsContext (Smack 4.4.0), shouldn’t the trustManagers default to those provided by an SSLContext obtained from the SslContextFactory that’s passed in as an argument to the method? WIth the implementation as-is, any TrustManager configuration that’s applied there is lost.

final TrustManager[] trustManagers;
if (trustManager != null) {
    trustManagers = new TrustManager[] { trustManager };
} else {
    // Ensure trustManagers is null in case there was no explicit trust manager provided, so that the
    // default one is used.
    trustManagers = null;
}

[Flow]

@guus

shouldn’t the trustManagers default to those provided by an SSLContext

A quick glance at SSLContext’s javadoc does not show a method to retireve its TrustManagers, but maybe I am missing something?

[guus]

I think you’re right. Although the migration to Smack 4.4.0 in Spark, introduced an anonymous SSLContextFactory that returns an already initialized SSLContext, such context probably shouldn’t be expected to be pre-initialized. I’m happy to chalk this up on wonkey integration in Spark.

[Flow]

@guus

SSLContextFactory that returns an already initialized SSLContext, such context probably shouldn’t be expected to be pre-initialized.

Right, I also believe this could be better documented in Smack. But it is also, at least partly, caused by the design of Java’s SSLContext API. In any case, if you want fine grained control of Smack’s TLS handling, then you want to load Smack’s ConnectionConfiguration with a factory for an uninitialized SSLContext and optional additional components like TrustManagers.