Regression on 4.9.0 after OF-2864 - Illegal base64

Openfire
1

When upgrading an existing server with an existing configuration from 4.8.3 to 4.9.0, the server can’t start anymore.

The following stacktrace highlight the issue:

java.lang.IllegalArgumentException: Illegal base64 character 20
        at java.base/java.util.Base64$Decoder.decode0(Base64.java:847)
        at java.base/java.util.Base64$Decoder.decode(Base64.java:566)
        at java.base/java.util.Base64$Decoder.decode(Base64.java:589)
        at org.jivesoftware.util.AesEncryptor.decrypt(AesEncryptor.java:100)
        at org.jivesoftware.util.AesEncryptor.decrypt(AesEncryptor.java:94)
        at org.jivesoftware.util.JiveGlobals.getCurrentKey(JiveGlobals.java:1128)
        at org.jivesoftware.util.JiveGlobals.setupPropertyEncryption(JiveGlobals.java:1329)
        at org.jivesoftware.util.JiveGlobals.loadSecurityProperties(JiveGlobals.java:1296)
        at org.jivesoftware.util.JiveGlobals.isXMLPropertyEncrypted(JiveGlobals.java:1010)
        at org.jivesoftware.util.XMLProperties.getProperty(XMLProperties.java:212)
        at org.jivesoftware.util.XMLProperties.getProperty(XMLProperties.java:171)
        at org.jivesoftware.util.JiveGlobals.getXMLProperty(JiveGlobals.java:310)
        at org.jivesoftware.openfire.XMPPServer.initialize(XMPPServer.java:366)
        at org.jivesoftware.openfire.XMPPServer.start(XMPPServer.java:660)
        at org.jivesoftware.openfire.XMPPServer.<init>(XMPPServer.java:220)
        at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
        at java.base/java.lang.reflect.ReflectAccess.newInstance(ReflectAccess.java:128)
        at java.base/jdk.internal.reflect.ReflectionFactory.newInstance(ReflectionFactory.java:347)
        at java.base/java.lang.Class.newInstance(Class.java:645)
        at org.jivesoftware.openfire.starter.ServerStarter.start(ServerStarter.java:92)
        at org.jivesoftware.openfire.starter.ServerStarter.main(ServerStarter.java:56)

The java.util.base64 class is used since [OF-2864] - Ignite Realtime Jira Deprecate custom Base64 class.

I’m not sure how to identify the string raising this issue.

2

Oh, that’s an annoying problem. You’re the first to report this, so I’m kind of hoping that it is unique to your server, for some reason.

It appears to happen when reading the file conf/security.xml. Can you check that file please?

3

The 20 character is a space, so try to trim spaces before any base64 string

4

So, indeed, I’ve checked this yesterday evening, the blowfish field contained a space in the MIDDLE of the string.

But when I remove it on 4.8.3 before starting again the server, then shutting it down, the space is actually put in back in the configuration file.

Removing the space again, starting 4.9.0, stopping 4.9.0, no space anymore, so that’s apparently the way the Base64 custom library SAVES the credentials that could create that issue.

If so, perhaps a transition code .replace(" ", “”) could be nice when reading those fields?

5

I have raised a ticket in our issue tracker for this problem: [OF-2883] - Ignite Realtime Jira