smpt: fix starttls

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

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
This commit is contained in:
Sebastian Neubauer 2024-03-05 02:11:46 +01:00 committed by Daniel Stenberg
parent 14bcea074a
commit a5dd9435ee
No known key found for this signature in database
GPG Key ID: 5CC908FDB71E12C2

View File

@ -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