improve ssl error code, 2147483650
Hi Hackers,
When configuring SSL on the Postgres server side with the following
information:
ssl = on
ssl_ca_file = 'root_ca.crt'
ssl_cert_file = 'server-cn-only.crt'
ssl_key_file = 'server-cn-only.key'
If a user makes a mistake, for example, accidentally using 'root_ca.crl'
instead of 'root_ca.crt', Postgres will report an error like the one below:
FATAL: could not load root certificate file "root_ca.crl": SSL error
code 2147483650
Here, the error code 2147483650 is not very helpful for the user. The
reason is that Postgres is missing the initial SSL file check before
passing it to the OpenSSL API. For example:
if (ssl_ca_file[0])
{
STACK_OF(X509_NAME) * root_cert_list;
if (SSL_CTX_load_verify_locations(context, ssl_ca_file, NULL)
!= 1 ||
(root_cert_list = SSL_load_client_CA_file(ssl_ca_file)) ==
NULL)
{
ereport(isServerStart ? FATAL : LOG,
(errcode(ERRCODE_CONFIG_FILE_ERROR),
errmsg("could not load root certificate file
\"%s\": %s",
ssl_ca_file, SSLerrmessage(ERR_get_error()))));
goto error;
}
The SSL_CTX_load_verify_locations function in OpenSSL will return NULL
if there is a system error, such as "No such file or directory" in this
case:
const char *ERR_reason_error_string(unsigned long e)
{
ERR_STRING_DATA d, *p = NULL;
unsigned long l, r;
if (!RUN_ONCE(&err_string_init, do_err_strings_init)) {
return NULL;
}
/*
* ERR_reason_error_string() can't safely return system error strings,
* since openssl_strerror_r() needs a buffer for thread safety, and we
* haven't got one that would serve any sensible purpose.
*/
if (ERR_SYSTEM_ERROR(e))
return NULL;
It would be better to perform a simple SSL file check before passing the
SSL file to OpenSSL APIs so that the system error can be captured and a
meaningful message provided to the end user.
Attached is a simple patch to help address this issue for ssl_ca_file,
ssl_cert_file, and ssl_crl_file. With this patch, a similar test will
return something like the message below:
FATAL: could not access certificate file "root_ca.crl": No such file or
directory
I believe this can help end users quickly realize the mistake.
Thank you,
David
Attachments:
0001-improve-ssl-files-error-code.patchtext/plain; charset=UTF-8; name=0001-improve-ssl-files-error-code.patchDownload
From bb6264791aab6a3e8150704fc8f1c8774c27018d Mon Sep 17 00:00:00 2001
From: David Zhang <idrawone@gmail.com>
Date: Wed, 6 Mar 2024 15:51:11 -0800
Subject: [PATCH] improve ssl files error code
---
src/backend/libpq/be-secure-common.c | 19 +++++++++++++++++++
src/backend/libpq/be-secure-openssl.c | 10 ++++++++++
src/include/libpq/libpq.h | 1 +
3 files changed, 30 insertions(+)
diff --git a/src/backend/libpq/be-secure-common.c b/src/backend/libpq/be-secure-common.c
index 0582606192..01d567cbfc 100644
--- a/src/backend/libpq/be-secure-common.c
+++ b/src/backend/libpq/be-secure-common.c
@@ -102,7 +102,26 @@ error:
return len;
}
+/*
+ * Check SSL certificate files.
+ */
+bool
+check_ssl_file(const char *ssl_file, bool isServerStart)
+{
+ int loglevel = isServerStart ? FATAL : LOG;
+ struct stat buf;
+
+ if (stat(ssl_file, &buf) != 0)
+ {
+ ereport(loglevel,
+ (errcode_for_file_access(),
+ errmsg("could not access certificate file \"%s\": %m",
+ ssl_file)));
+ return false;
+ }
+ return true;
+}
/*
* Check permissions for SSL key files.
*/
diff --git a/src/backend/libpq/be-secure-openssl.c b/src/backend/libpq/be-secure-openssl.c
index e12b1cc9e3..c5d58545d9 100644
--- a/src/backend/libpq/be-secure-openssl.c
+++ b/src/backend/libpq/be-secure-openssl.c
@@ -144,6 +144,10 @@ be_tls_init(bool isServerStart)
/*
* Load and verify server's certificate and private key
*/
+
+ if (!check_ssl_file(ssl_cert_file, isServerStart))
+ goto error;
+
if (SSL_CTX_use_certificate_chain_file(context, ssl_cert_file) != 1)
{
ereport(isServerStart ? FATAL : LOG,
@@ -297,6 +301,9 @@ be_tls_init(bool isServerStart)
{
STACK_OF(X509_NAME) * root_cert_list;
+ if (!check_ssl_file(ssl_ca_file, isServerStart))
+ goto error;
+
if (SSL_CTX_load_verify_locations(context, ssl_ca_file, NULL) != 1 ||
(root_cert_list = SSL_load_client_CA_file(ssl_ca_file)) == NULL)
{
@@ -336,6 +343,9 @@ be_tls_init(bool isServerStart)
{
X509_STORE *cvstore = SSL_CTX_get_cert_store(context);
+ if (ssl_crl_file[0] && !check_ssl_file(ssl_crl_file, isServerStart))
+ goto error;
+
if (cvstore)
{
/* Set the flags to check against the complete CRL chain */
diff --git a/src/include/libpq/libpq.h b/src/include/libpq/libpq.h
index 6171a0d17a..a491f0caa9 100644
--- a/src/include/libpq/libpq.h
+++ b/src/include/libpq/libpq.h
@@ -140,5 +140,6 @@ extern int run_ssl_passphrase_command(const char *prompt, bool is_server_start,
char *buf, int size);
extern bool check_ssl_key_file_permissions(const char *ssl_key_file,
bool isServerStart);
+extern bool check_ssl_file(const char *ssl_file, bool isServerStart);
#endif /* LIBPQ_H */
--
2.34.1
On 07/03/2024 02:12, David Zhang wrote:
The SSL_CTX_load_verify_locations function in OpenSSL will return NULL
if there is a system error, such as "No such file or directory" in this
case:const char *ERR_reason_error_string(unsigned long e)
{
ERR_STRING_DATA d, *p = NULL;
unsigned long l, r;if (!RUN_ONCE(&err_string_init, do_err_strings_init)) {
return NULL;
}/*
* ERR_reason_error_string() can't safely return system error strings,
* since openssl_strerror_r() needs a buffer for thread safety, and we
* haven't got one that would serve any sensible purpose.
*/
if (ERR_SYSTEM_ERROR(e))
return NULL;
That's pretty unfortunate. As typical with OpenSSL, this stuff is not
very well documented, but I think we could do something like this in
SSLerrmessage():
if (ERR_SYSTEM_ERROR(e))
errreason = strerror(ERR_GET_REASON(e));
ERR_SYSTEM_ERROR only exists in OpenSSL 3.0 and above, and the only
documentation I could find was in this one obscure place in the man
pages:
https://www.openssl.org/docs/man3.2/man3/BIO_dgram_get_local_addr_enable.html.
But as a best-effort thing, it would still be better than "SSL error
code 2147483650".
It would be better to perform a simple SSL file check before passing the
SSL file to OpenSSL APIs so that the system error can be captured and a
meaningful message provided to the end user.
That feels pretty ugly. I agree it would catch most of the common
mistakes in practice, so maybe we should just hold our noses and do it
anyway, if the above ERR_SYSTEM_ERROR() method doesn't work.
It's sad that we cannot pass a file descriptor or in-memory copy of the
file contents to those functions.
--
Heikki Linnakangas
Neon (https://neon.tech)
Greetings,
* Heikki Linnakangas (hlinnaka@iki.fi) wrote:
On 07/03/2024 02:12, David Zhang wrote:
The SSL_CTX_load_verify_locations function in OpenSSL will return NULL
if there is a system error, such as "No such file or directory" in this
case:const char *ERR_reason_error_string(unsigned long e)
{
ERR_STRING_DATA d, *p = NULL;
unsigned long l, r;if (!RUN_ONCE(&err_string_init, do_err_strings_init)) {
return NULL;
}/*
* ERR_reason_error_string() can't safely return system error strings,
* since openssl_strerror_r() needs a buffer for thread safety, and we
* haven't got one that would serve any sensible purpose.
*/
if (ERR_SYSTEM_ERROR(e))
return NULL;That's pretty unfortunate. As typical with OpenSSL, this stuff is not very
well documented, but I think we could do something like this in
SSLerrmessage():if (ERR_SYSTEM_ERROR(e))
errreason = strerror(ERR_GET_REASON(e));ERR_SYSTEM_ERROR only exists in OpenSSL 3.0 and above, and the only
documentation I could find was in this one obscure place in the man pages: https://www.openssl.org/docs/man3.2/man3/BIO_dgram_get_local_addr_enable.html.
But as a best-effort thing, it would still be better than "SSL error code
2147483650".
Agreed that it doesn't seem well documented. I was trying to figure out
what the 'right' answer here was myself and not having much success. If
the above works, then +1 to that.
It would be better to perform a simple SSL file check before passing the
SSL file to OpenSSL APIs so that the system error can be captured and a
meaningful message provided to the end user.That feels pretty ugly. I agree it would catch most of the common mistakes
in practice, so maybe we should just hold our noses and do it anyway, if the
above ERR_SYSTEM_ERROR() method doesn't work.
Yeah, seems better to try and handle this the OpenSSL way ... if that's
possible to do.
It's sad that we cannot pass a file descriptor or in-memory copy of the file
contents to those functions.
Agreed.
Thanks!
Stephen
Stephen Frost <sfrost@snowman.net> writes:
* Heikki Linnakangas (hlinnaka@iki.fi) wrote:
That's pretty unfortunate. As typical with OpenSSL, this stuff is not very
well documented, but I think we could do something like this in
SSLerrmessage():if (ERR_SYSTEM_ERROR(e))
errreason = strerror(ERR_GET_REASON(e));ERR_SYSTEM_ERROR only exists in OpenSSL 3.0 and above, and the only
documentation I could find was in this one obscure place in the man pages: https://www.openssl.org/docs/man3.2/man3/BIO_dgram_get_local_addr_enable.html.
But as a best-effort thing, it would still be better than "SSL error code
2147483650".
Agreed that it doesn't seem well documented. I was trying to figure out
what the 'right' answer here was myself and not having much success. If
the above works, then +1 to that.
My reaction as well --- I was just gearing up to test this idea,
unless one of you are already on it?
regards, tom lane
David Zhang <david.zhang@highgo.ca> writes:
When configuring SSL on the Postgres server side with the following
information:
ssl = on
ssl_ca_file = 'root_ca.crt'
ssl_cert_file = 'server-cn-only.crt'
ssl_key_file = 'server-cn-only.key'
If a user makes a mistake, for example, accidentally using 'root_ca.crl'
instead of 'root_ca.crt', Postgres will report an error like the one below:
FATAL: could not load root certificate file "root_ca.crl": SSL error
code 2147483650
Interestingly, this works fine for me on RHEL8 (with openssl-1.1.1k):
2024-03-07 12:57:53.432 EST [547522] FATAL: F0000: could not load root certificate file "foo.bar": No such file or directory
2024-03-07 12:57:53.432 EST [547522] LOCATION: be_tls_init, be-secure-openssl.c:306
I do reproduce your problem on Fedora 39 with openssl-3.1.1.
So this seems to be a regression on OpenSSL's part. Maybe
they'll figure out how to fix it sometime; that seems to be
another good argument for not pre-empting their error handling.
regards, tom lane
I wrote:
Stephen Frost <sfrost@snowman.net> writes:
Agreed that it doesn't seem well documented. I was trying to figure out
what the 'right' answer here was myself and not having much success. If
the above works, then +1 to that.
My reaction as well --- I was just gearing up to test this idea,
unless one of you are already on it?
I've confirmed that this:
diff --git a/src/backend/libpq/be-secure-openssl.c b/src/backend/libpq/be-secure-openssl.c
index e12b1cc9e3..47eee4b59d 100644
--- a/src/backend/libpq/be-secure-openssl.c
+++ b/src/backend/libpq/be-secure-openssl.c
@@ -1363,6 +1363,10 @@ SSLerrmessage(unsigned long ecode)
errreason = ERR_reason_error_string(ecode);
if (errreason != NULL)
return errreason;
+#ifdef ERR_SYSTEM_ERROR
+ if (ERR_SYSTEM_ERROR(ecode))
+ return strerror(ERR_GET_REASON(ecode));
+#endif
snprintf(errbuf, sizeof(errbuf), _("SSL error code %lu"), ecode);
return errbuf;
}seems to be enough to fix the problem on OpenSSL 3.1.1. The #ifdef
is needed to avoid compile failure against OpenSSL 1.1.1 --- but that
version doesn't have the problem, so we don't need to sweat.
This could probably do with a comment, and we need to propagate
the fix into libpq's copy of the function too. Barring objections,
I'll take care of that and push it later today.
regards, tom lane
On 7 Mar 2024, at 20:58, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I wrote:
Stephen Frost <sfrost@snowman.net> writes:
Agreed that it doesn't seem well documented. I was trying to figure out
what the 'right' answer here was myself and not having much success. If
the above works, then +1 to that.My reaction as well --- I was just gearing up to test this idea,
unless one of you are already on it?I've confirmed that this:
diff --git a/src/backend/libpq/be-secure-openssl.c b/src/backend/libpq/be-secure-openssl.c index e12b1cc9e3..47eee4b59d 100644 --- a/src/backend/libpq/be-secure-openssl.c +++ b/src/backend/libpq/be-secure-openssl.c @@ -1363,6 +1363,10 @@ SSLerrmessage(unsigned long ecode) errreason = ERR_reason_error_string(ecode); if (errreason != NULL) return errreason; +#ifdef ERR_SYSTEM_ERROR + if (ERR_SYSTEM_ERROR(ecode)) + return strerror(ERR_GET_REASON(ecode)); +#endif snprintf(errbuf, sizeof(errbuf), _("SSL error code %lu"), ecode); return errbuf; }seems to be enough to fix the problem on OpenSSL 3.1.1. The #ifdef
is needed to avoid compile failure against OpenSSL 1.1.1 --- but that
version doesn't have the problem, so we don't need to sweat.
This was introduced in OpenSSL 3.0.0 so that makes sense. Pre-3.0.0 versions
truncates system errorcodes that was outside of the range 1..127 reserving the
rest for OpenSSL specific errors. To capture the full range possible of system
errors the code is no longer truncated and the ERR_SYSTEM_FLAG flag is set,
which can be tested for with the macro used here.
This could probably do with a comment, and we need to propagate
the fix into libpq's copy of the function too. Barring objections,
I'll take care of that and push it later today.
LGTM.
--
Daniel Gustafsson
Daniel Gustafsson <daniel@yesql.se> writes:
On 7 Mar 2024, at 20:58, Tom Lane <tgl@sss.pgh.pa.us> wrote:
This could probably do with a comment, and we need to propagate
the fix into libpq's copy of the function too. Barring objections,
I'll take care of that and push it later today.
LGTM.
Done so far as be-secure-openssl.c and fe-secure-openssl.c are
concerned. But I noticed that src/common/cryptohash_openssl.c and
src/common/hmac_openssl.c have their own, rather half-baked versions
of SSLerrmessage. I didn't do anything about that in the initial
patch, because it's not clear to me that those routines would ever
see system-errno-based errors, plus their comments claim that
returning NULL isn't terribly bad. But if we want to do something
about it, I don't think that maintaining 3 copies of the code is the
way to go. Maybe push be-secure-openssl.c's version into src/common?
regards, tom lane
On 08.03.24 01:46, Tom Lane wrote:
Daniel Gustafsson <daniel@yesql.se> writes:
On 7 Mar 2024, at 20:58, Tom Lane <tgl@sss.pgh.pa.us> wrote:
This could probably do with a comment, and we need to propagate
the fix into libpq's copy of the function too. Barring objections,
I'll take care of that and push it later today.LGTM.
Done so far as be-secure-openssl.c and fe-secure-openssl.c are
concerned.
I noticed that this change uses not-thread-safe strerror() in libpq code.
Perhaps something like this would be better (and simpler):
diff --git a/src/interfaces/libpq/fe-secure-openssl.c
b/src/interfaces/libpq/fe-secure-openssl.c
index 5c867106fb0..14cd9ce404d 100644
--- a/src/interfaces/libpq/fe-secure-openssl.c
+++ b/src/interfaces/libpq/fe-secure-openssl.c
@@ -1767,7 +1767,7 @@ SSLerrmessage(unsigned long ecode)
#ifdef ERR_SYSTEM_ERROR
if (ERR_SYSTEM_ERROR(ecode))
{
- strlcpy(errbuf, strerror(ERR_GET_REASON(ecode)), SSL_ERR_LEN);
+ strerror_r(ERR_GET_REASON(ecode), errbuf, SSL_ERR_LEN);
return errbuf;
}
#endifOn 21 Jun 2024, at 13:15, Peter Eisentraut <peter@eisentraut.org> wrote:
I noticed that this change uses not-thread-safe strerror() in libpq code.
Perhaps something like this would be better (and simpler):
Nice catch, LGTM.
--
Daniel Gustafsson
Peter Eisentraut <peter@eisentraut.org> writes:
- strlcpy(errbuf, strerror(ERR_GET_REASON(ecode)), SSL_ERR_LEN); + strerror_r(ERR_GET_REASON(ecode), errbuf, SSL_ERR_LEN);
Most of libpq gets at strerror_r via SOCK_STRERROR for Windows
portability. Is that relevant here?
regards, tom lane
On 21.06.24 16:53, Tom Lane wrote:
Peter Eisentraut <peter@eisentraut.org> writes:
- strlcpy(errbuf, strerror(ERR_GET_REASON(ecode)), SSL_ERR_LEN); + strerror_r(ERR_GET_REASON(ecode), errbuf, SSL_ERR_LEN);Most of libpq gets at strerror_r via SOCK_STRERROR for Windows
portability. Is that relevant here?
Looking inside the OpenSSL code, it makes no efforts to translate
between winsock error codes and standard error codes, so I don't think
our workaround/replacement code needs to do that either.
Btw., our source code comments say something like
"ERR_reason_error_string randomly refuses to map system errno values."
The reason it doesn't is exactly that it can't do it while maintaining
thread-safety. Here is the relevant commit:
https://github.com/openssl/openssl/commit/71f2994b15
Peter Eisentraut <peter@eisentraut.org> writes:
On 21.06.24 16:53, Tom Lane wrote:
Most of libpq gets at strerror_r via SOCK_STRERROR for Windows
portability. Is that relevant here?
Looking inside the OpenSSL code, it makes no efforts to translate
between winsock error codes and standard error codes, so I don't think
our workaround/replacement code needs to do that either.
Fair enough.
Btw., our source code comments say something like
"ERR_reason_error_string randomly refuses to map system errno values."
The reason it doesn't is exactly that it can't do it while maintaining
thread-safety.
Ah. Do you want to improve that comment while you're at it?
regards, tom lane
On 25.06.24 16:21, Tom Lane wrote:
Peter Eisentraut <peter@eisentraut.org> writes:
On 21.06.24 16:53, Tom Lane wrote:
Most of libpq gets at strerror_r via SOCK_STRERROR for Windows
portability. Is that relevant here?Looking inside the OpenSSL code, it makes no efforts to translate
between winsock error codes and standard error codes, so I don't think
our workaround/replacement code needs to do that either.Fair enough.
Btw., our source code comments say something like
"ERR_reason_error_string randomly refuses to map system errno values."
The reason it doesn't is exactly that it can't do it while maintaining
thread-safety.Ah. Do you want to improve that comment while you're at it?
Here is a patch that fixes the strerror() call and updates the comments
a bit.
This ought to be backpatched like the original fix; ideally for the next
minor releases in about two weeks.
Attachments:
0001-libpq-Use-strerror_r-instead-of-strerror.patchtext/plain; charset=UTF-8; name=0001-libpq-Use-strerror_r-instead-of-strerror.patchDownload
From fb61f5f897e6151957b6ea6e2dfd7905b48b7ca2 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@eisentraut.org>
Date: Wed, 24 Jul 2024 14:58:12 +0200
Subject: [PATCH] libpq: Use strerror_r instead of strerror
Commit 453c4687377 introduced a use of strerror() into libpq, but that
is not thread-safe. Fix by using strerror_r() instead.
In passing, update some of the code comments added by 453c4687377, as
we have learned more about the reason for the change in OpenSSL that
started this.
Discussion: Discussion: https://postgr.es/m/b6fb018b-f05c-4afd-abd3-318c649faf18@highgo.ca
---
src/backend/libpq/be-secure-openssl.c | 9 +++++----
src/interfaces/libpq/fe-secure-openssl.c | 11 ++++++-----
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/src/backend/libpq/be-secure-openssl.c b/src/backend/libpq/be-secure-openssl.c
index 39b1a66236b..95b4d94a2e6 100644
--- a/src/backend/libpq/be-secure-openssl.c
+++ b/src/backend/libpq/be-secure-openssl.c
@@ -1453,10 +1453,11 @@ SSLerrmessage(unsigned long ecode)
return errreason;
/*
- * In OpenSSL 3.0.0 and later, ERR_reason_error_string randomly refuses to
- * map system errno values. We can cover that shortcoming with this bit
- * of code. Older OpenSSL versions don't have the ERR_SYSTEM_ERROR macro,
- * but that's okay because they don't have the shortcoming either.
+ * In OpenSSL 3.0.0 and later, ERR_reason_error_string does not map system
+ * errno values anymore. (See OpenSSL source code for the explanation.)
+ * We can cover that shortcoming with this bit of code. Older OpenSSL
+ * versions don't have the ERR_SYSTEM_ERROR macro, but that's okay because
+ * they don't have the shortcoming either.
*/
#ifdef ERR_SYSTEM_ERROR
if (ERR_SYSTEM_ERROR(ecode))
diff --git a/src/interfaces/libpq/fe-secure-openssl.c b/src/interfaces/libpq/fe-secure-openssl.c
index 5c867106fb0..b6fffd7b9b0 100644
--- a/src/interfaces/libpq/fe-secure-openssl.c
+++ b/src/interfaces/libpq/fe-secure-openssl.c
@@ -1759,15 +1759,16 @@ SSLerrmessage(unsigned long ecode)
#endif
/*
- * In OpenSSL 3.0.0 and later, ERR_reason_error_string randomly refuses to
- * map system errno values. We can cover that shortcoming with this bit
- * of code. Older OpenSSL versions don't have the ERR_SYSTEM_ERROR macro,
- * but that's okay because they don't have the shortcoming either.
+ * In OpenSSL 3.0.0 and later, ERR_reason_error_string does not map system
+ * errno values anymore. (See OpenSSL source code for the explanation.)
+ * We can cover that shortcoming with this bit of code. Older OpenSSL
+ * versions don't have the ERR_SYSTEM_ERROR macro, but that's okay because
+ * they don't have the shortcoming either.
*/
#ifdef ERR_SYSTEM_ERROR
if (ERR_SYSTEM_ERROR(ecode))
{
- strlcpy(errbuf, strerror(ERR_GET_REASON(ecode)), SSL_ERR_LEN);
+ strerror_r(ERR_GET_REASON(ecode), errbuf, SSL_ERR_LEN);
return errbuf;
}
#endif
--
2.45.2
On 24 Jul 2024, at 15:32, Peter Eisentraut <peter@eisentraut.org> wrote:
On 25.06.24 16:21, Tom Lane wrote:
Peter Eisentraut <peter@eisentraut.org> writes:
On 21.06.24 16:53, Tom Lane wrote:
Most of libpq gets at strerror_r via SOCK_STRERROR for Windows
portability. Is that relevant here?Looking inside the OpenSSL code, it makes no efforts to translate
between winsock error codes and standard error codes, so I don't think
our workaround/replacement code needs to do that either.Fair enough.
Btw., our source code comments say something like
"ERR_reason_error_string randomly refuses to map system errno values."
The reason it doesn't is exactly that it can't do it while maintaining
thread-safety.Ah. Do you want to improve that comment while you're at it?
Here is a patch that fixes the strerror() call and updates the comments a bit.
LGTM.
This ought to be backpatched like the original fix; ideally for the next minor releases in about two weeks.
Agreed.
--
Daniel Gustafsson
On 25.07.24 11:36, Daniel Gustafsson wrote:
On 24 Jul 2024, at 15:32, Peter Eisentraut <peter@eisentraut.org> wrote:
On 25.06.24 16:21, Tom Lane wrote:
Peter Eisentraut <peter@eisentraut.org> writes:
On 21.06.24 16:53, Tom Lane wrote:
Most of libpq gets at strerror_r via SOCK_STRERROR for Windows
portability. Is that relevant here?Looking inside the OpenSSL code, it makes no efforts to translate
between winsock error codes and standard error codes, so I don't think
our workaround/replacement code needs to do that either.Fair enough.
Btw., our source code comments say something like
"ERR_reason_error_string randomly refuses to map system errno values."
The reason it doesn't is exactly that it can't do it while maintaining
thread-safety.Ah. Do you want to improve that comment while you're at it?
Here is a patch that fixes the strerror() call and updates the comments a bit.
LGTM.
This ought to be backpatched like the original fix; ideally for the next minor releases in about two weeks.
Agreed.
done