changeset: 6813:a9764761b692 user: <g...@libero.it> date: Mon Oct 10 16:33:13 2016 -0700 link: http://dev.mutt.org/hg/mutt/rev/a9764761b692
Fix POP3 SASL authentication mechanism DIGEST-MD5. (closes #3862) sasl_client_step() returns SASL_OK after the fourth step: server auth confirmation. However, the protocol requires the client send one more blank line to the server, to which the server then replies with "+OK". See https://tools.ietf.org/html/rfc5034#section-6. The code currently only sends a final response if sasl_client_step returns data to send. Change it to always send a final client message after the SASL_OK. changeset: 6814:33d16ccba4cf user: Kevin McCarthy <ke...@8t8.us> date: Mon Oct 10 18:09:00 2016 -0700 link: http://dev.mutt.org/hg/mutt/rev/33d16ccba4cf Add a few explanatory comments to pop_auth_sasl(). (see #3862) diffs (38 lines): diff -r 4bcc3a12cc4d -r 33d16ccba4cf pop_auth.c --- a/pop_auth.c Sat Oct 08 13:24:00 2016 -0700 +++ b/pop_auth.c Mon Oct 10 18:09:00 2016 -0700 @@ -74,6 +74,10 @@ return POP_A_UNAVAIL; } + /* About client_start: If sasl_client_start() returns data via pc/olen, + * the client is expected to send this first (after the AUTH string is sent). + * sasl_client_start() may in fact return SASL_OK in this case. + */ client_start = olen; mutt_message _("Authenticating (SASL)..."); @@ -97,6 +101,11 @@ return POP_A_SOCKET; } + /* Note we don't exit if rc==SASL_OK when client_start is true. + * This is because the first loop has only sent the AUTH string, we + * need to loop at least once more to send the pc/olen returned + * by sasl_client_start(). + */ if (!client_start && rc != SASL_CONTINUE) break; @@ -121,7 +130,10 @@ client_start = 0; } - if (rc != SASL_CONTINUE && (olen == 0 || rc != SASL_OK)) + /* Even if sasl_client_step() returns SASL_OK, we should send at + * least one more line to the server. See #3862. + */ + if (rc != SASL_CONTINUE && rc != SASL_OK) break; /* send out response, or line break if none needed */
