2.4 sieveshell cannot talk GSSAPI to 2.4 server due to base64 incompatibility?

[James Ralston]

OK, I'm stumped: how on earth is the 2.4 sieveshell utility
actually supposed to be able to talk to a 2.4 timsieved server?

We're using cyrus-imapd-2.4.17-8.el7_1 and cyrus-sasl-2.1.26-20.el7_2
on Red Hat Enterprise Linux 7.3, using Active Directory as our Keberos
KDC.  The issue we're seeing is that sieveshell sends binary data when
performing GSSAPI authentication, which the server rejects:

S: "IMPLEMENTATION" "Cyrus timsieved v2.4.17-Fedora-RPM-2.4.17-8.el7_1"
S: "SASL" "GSSAPI"
S: "SIEVE" "comparator-i;ascii-numeric fileinto reject vacation
imapflags notify envelope relational regex subaddress copy"
S: "STARTTLS"
S: "UNAUTHENTICATE"
S: OK
C: AUTHENTICATE "GSSAPI" {3132+}
C: [binary data]
S: NO "Authentication Error"

The server rejects the authenticate attempt because it expects the
initial client challenge to be base64-encoded, because it
unconditionally calls sasl_decode64() on the client challenge, in
timsieved/parser.c, function cmd_authenticate():

May 31 11:37:45 server sieve[8053]: badlogin:
client.example.org[1.2.3.4] GSSAPI error base64 decoding string

In order to prove that the server was expecting base64, I applied this
debugging patch to parser.c:

diff -up cyrus-imapd-2.4.17/timsieved/parser.c.sieveshell-decode64
cyrus-imapd-2.4.17/timsieved/parser.c
--- cyrus-imapd-2.4.17/timsieved/parser.c.sieveshell-decode64
2012-12-01 14:57:54.000000000 -0500
+++ cyrus-imapd-2.4.17/timsieved/parser.c 2017-05-31 14:13:48.317516769 -0400
@@ -623,9 +623,17 @@ static int cmd_authenticate(struct prots

       if (sasl_result!=SASL_OK)
       {
+ char *clientinstr_b64_encoded;
+ clientinstr_b64_encoded = calloc(clientinstr->len*2+1, 1);
+ sasl_encode64(string_DATAPTR(clientinstr), clientinstr->len,
+      clientinstr_b64_encoded, clientinstr->len*2, NULL);
  *errmsg="error base64 decoding string";
- syslog(LOG_NOTICE, "badlogin: %s %s %s",
-       sieved_clienthost, mech, "error base64 decoding string");
+ syslog(LOG_NOTICE,
+       "badlogin: sasl_decode64 failed: client %s, mech %s: initial
challenge %s: %s",
+       sieved_clienthost, mech,
+       clientinstr_b64_encoded,
+       sasl_errstring(sasl_result, NULL, NULL));
+ free(clientinstr_b64_encoded);

       if(reset_saslconn(&sieved_saslconn, ssf, authid) != SASL_OK)
   fatal("could not reset the sasl_conn_t after failure",
@@ -673,9 +681,17 @@ static int cmd_authenticate(struct prots

       if (sasl_result!=SASL_OK)
       {
+ char *clientinstr_b64_encoded;
+ clientinstr_b64_encoded = calloc(clientinstr->len*2+1, 1);
+ sasl_encode64(string_DATAPTR(clientinstr), clientinstr->len,
+      clientinstr_b64_encoded, clientinstr->len*2, NULL);
  *errmsg="error base64 decoding string";
- syslog(LOG_NOTICE, "badlogin: %s %s %s",
-       sieved_clienthost, mech, "error base64 decoding string");
+ syslog(LOG_NOTICE,
+       "badlogin: sasl_decode64 failed: client %s, mech %s:
sasl_continue %s: %s",
+       sieved_clienthost, mech,
+       clientinstr_b64_encoded,
+       sasl_errstring(sasl_result, NULL, NULL));
+ free(clientinstr_b64_encoded);

       if(reset_saslconn(&sieved_saslconn, ssf, authid) != SASL_OK)
   fatal("could not reset the sasl_conn_t after failure",

That yielded this log message:

May 31 14:26:26 server sieve[23075]: badlogin: sasl_decode64 failed:
client client.example.org[1.2.3.4], mech GSSAPI: initial challenge
[base64 blob ommitted]: bad protocol / cancel

If the client had sent a base64-encoded challenge, then decoding
[base64 blob omitted] should have resulted in another base64-encoded
string.  But instead, decoding [base64 blob omitted] yields the binary
blob the client sent.  So yes, of *course* sasl_decode64() failed: the
input wasn't base64-encoded text.

Was this a known bug in the sieve implementation in the 2.4 series?
If so, in what release was it fixed, and is there any chance of
backporting the fix to the 2.4 series?

(We'd really prefer to stick with the cyrus-imapd RPMs that Red Hat
provides, rather than rolling our own, because then we're on the hook
for addressing security vulnerabilities instead of Red Hat.)

Thanks in advance for any pointers/advice.