powered by Jive Software

Smack 4.3.4: SASLGSSAPIMechanism sets a system property in a static block creating issues

We are using smack to connect to Firebase through XMPP and it is working like charm. Thank you for your effort and share.
Nevertheless, we encountered issues accessing to our VMs through JMX and the issue was coming from the setting “java.security.auth.login.config” in a static block within SASLGSSAPIMechanism class.

public class SASLGSSAPIMechanism extends SASLJavaXMechanism {

    public static final String NAME = GSSAPI;

    static {

The encountered error is:

java.lang.SecurityException: java.io.IOException: gss.conf (No such file or directory)
    at sun.security.provider.ConfigFile$Spi.<init>(ConfigFile.java:137)
    at sun.security.provider.ConfigFile.<init>(ConfigFile.java:102)
    at sun.reflect.GeneratedConstructorAccessor119.newInstance(Unknown Source)

Is it possible to add the possibility to avoid registering a given SASL Mechanism ? Or set these system properties only if the SASL mechanism is whitelisted ?

Thank you for your time and cooperation,

I think you can use SASLAuthentication.unregisterSASLMechanism

so something like SASLAuthentication.unregisterSASLMechanism(SASLGSSAPIMechanism.class.getName());

Thank you for your response. I tried your proposition but since the system property is initialized in a static block and the registration is done in the SASLJavaXSmackInitializer, the unregister will not rollback the change done on the system property.
Initializing SASL mechanisms based on config can be more appropriate to avoid this issue.

You could add SASLJavaXSmackInitializer to the disabled classes in SmackConfiguration and then only load the SASL mechanisms from smack-java7 that you need. This will prevent the static code block in SASLGSSAPIMechanism from being executed.

That said, I have remove the static block with

Hi Flow,
Thank you for your response and your reactivity.
I will upgrade the library once the fix integrated.