Security, Site Health: Do not store HTTPS request error messages in an option.

This changes the logic in `update_https_detection_errors()` to never store error messages from the actual request since they could use a different encoding, which would make storing them in an option potentially fail, leading WordPress to then falsely assume that HTTPS is supported.

While this doesn't actually fix the encoding issue, it is not crucial to do so anyway, since these messages are not used anywhere. A simple differentiation between whether the overall HTTPS request or only the SSL verification failed should be sufficient for the purpose of this function.

Props flixos90, tmatsuur, lukecarbis.
Reviewed by flixos90, SergeyBiryukov.
Merges [50471] to the 5.7 branch.
Fixes #52484.
Built from https://develop.svn.wordpress.org/branches/5.7@50472


git-svn-id: http://core.svn.wordpress.org/branches/5.7@50083 1a063a9b-81f0-0310-95a4-ce76da25c4cd

wp-includes/https-detection.php

@@ -130,13 +130,13 @@ function wp_update_https_detection_errors() {
 
 		if ( is_wp_error( $unverified_response ) ) {
 			$support_errors->add(
-				$unverified_response->get_error_code(),
-				$unverified_response->get_error_message()
+				'https_request_failed',
+				__( 'HTTPS request failed.' )
 			);
 		} else {
 			$support_errors->add(
 				'ssl_verification_failed',
-				$response->get_error_message()
+				__( 'SSL verification failed.' )
 			);
 		}
 

wp-includes/version.php

@@ -13,7 +13,7 @@
  *
  * @global string $wp_version
  */
-$wp_version = '5.7-RC1-50470';
+$wp_version = '5.7-RC1-50472';
 
 /**
  * Holds the WordPress DB revision, increments when changes are made to the WordPress DB schema.