Re: improve ssl error code, 2147483650
От | Heikki Linnakangas |
---|---|
Тема | Re: improve ssl error code, 2147483650 |
Дата | |
Msg-id | 86932ed6-e4b3-44cd-abf2-7f0173dea782@iki.fi обсуждение исходный текст |
Ответ на | improve ssl error code, 2147483650 (David Zhang <david.zhang@highgo.ca>) |
Ответы |
Re: improve ssl error code, 2147483650
|
Список | pgsql-hackers |
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)
В списке pgsql-hackers по дате отправления: