smpt: fix starttls

In cases where the connection was fast, curl sometimes failed to open a
connection. This fixes a regression of c2d973627bab12abc5486a3f3.

The regression triggered in these steps:

1. Create an smtp connection
2. Use STARTTLS
3. Receive the response
4. We are inside the loop in `smtp_statemachine`, calling
   `smtp_state_starttls_resp`
5. In the good flow, we exit the loop, re-enter `smtp_statemachine` and
   run `smtp_perform_upgrade_tls` at the start of the function.

   In the bad flow, we stay in the while loop, calling
   `Curl_pp_readresp`, which reads part of the TLS handshake and things
   go wrong.

The reason is that `Curl_pp_moredata` changed behavior and always
returns `true`, so we stay in the loop in `smtp_statemachine`. With a
slow connection `Curl_pp_readresp` cannot read new data and returns
`CURL_AGAIN`, so we leave the loop and re-enter `smtp_statemachine`.

With a fast connection, `Curl_pp_readresp` reads new data from the tcp
connection, which is part of the TLS handshake.

The fix is in `Curl_pp_moredata`, which needs to take the final line
into account and return `false` if only the final line is stored.

Closes #13048

diff --git a/lib/pingpong.c b/lib/pingpong.c
index 7f240be9500d44c0397dc74ae5d490f79b0d73f7..81576c08c904bad5188452e98585c732eee08b88 100644 (file)
--- a/lib/pingpong.c
+++ b/lib/pingpong.c
@@ -432,7 +432,7 @@ CURLcode Curl_pp_disconnect(struct pingpong *pp)
 
 bool Curl_pp_moredata(struct pingpong *pp)
 {
-  return (!pp->sendleft && Curl_dyn_len(&pp->recvbuf));
+  return (!pp->sendleft && Curl_dyn_len(&pp->recvbuf) > pp->nfinal);
 }
 
 #endif