Bug in OpenFire SASL handling

(Apologies if this isn’t an appropriate place to post this; hopefully it will help people debug this problem that I’ve been troubleshooting for the last few days.)

In src/java/org/jivesoftware/openfire/net/SASLAuthentication.java is this code:

private static final Pattern BASE64_ENCODED = Pattern.compile("^(=|([A-Za-z0-9+/]{4})*([A-Za-z0-9+/]{4}|[A-Za-z0-9+/]{3}=|[A- Za-z0-9+/]{2}==))$");

This makes the assumption that there is content in every stepwise reply. SASL allows the client to reply with empty strings, which allow the server to perform more work and send additional data before continuing. GSSAPI / Kerberos does exactly this; therefore, the base64 regex test above causes “invalid-encoding” XMPP errors to be sent to the client in the middle of SASL negotiation.

Modifying the pattern thusly fixes the issue, allowing an empty string in addition to base64 content:

private static final Pattern BASE64_ENCODED = Pattern.compile("^((=|([A-Za-z0-9+/]{4})*([A-Za-z0-9+/]{4}|[A-Za-z0-9+/]{3}=|[A -Za-z0-9+/]{2}==)))?$");

This has been raised here already:

Openfire GSSAPI / Kerberos login no longer working with 3.10.0

I think empty strings are only allowed in the element but not in . (Extensible Messaging and Presence Protocol (XMPP): Core )

It has already been fixed:

https://github.com/igniterealtime/Openfire/commit/c9653b01e4a95cad420e6ad020ade4 29d4f3f269

Great. Four days of scouring the web didn’t find that thread. Maybe two separate threads will help folks find it.