Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1riGIW-00G39y-Mx for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Mar 2024 16:08:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1riGIU-006VxE-Ng for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Mar 2024 16:08:43 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1riGIU-006Vx3-Ay for pgsql-hackers@lists.postgresql.org; Thu, 07 Mar 2024 16:08:42 +0000 Received: from lahtoruutu.iki.fi ([2a0b:5c81:1c1::37]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1riGIQ-003Hpg-5s for pgsql-hackers@lists.postgresql.org; Thu, 07 Mar 2024 16:08:42 +0000 Received: from [192.168.1.115] (dsl-hkibng22-54f8db-125.dhcp.inet.fi [84.248.219.125]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: hlinnaka) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 4TrDkC73B7z49Q5W; Thu, 7 Mar 2024 18:08:35 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1709827716; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CX3BcC7AzVsYM75tq6Nhb88LgDGsmW1NCUeBnEyNTzU=; b=eL3waOZ4e0FjvgXxwA7Yqa2Q58j/5yq76OkuQfd2vpArVQhTCPVn+Yvn/sqnclg83iNpRC UhjXgpac7AGDr9mM/nS0aXodAjytD2ILJ6Q6JzK+9aOPaNbc3Z4zBRz6Lbj+rZsW3WCq0i 17VZ8E3GNLoEbP49iF7akjTuzhafQCOUzmZUuY7eP8nBZGV//qzW1kr//iqMvfYBcfOlvI NQGJxcRzLs/ma3/BrxcKURaZ2GVo8tZN6fWEa3392zruA/CBYGMJWFaowqsUquB7nd1qL/ PMU0NJOjsDyjHRWUhbHBj1wD1CsE9+cs+5Ml5c1frhAai+XscKhw1AEMyfCNMw== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1709827716; a=rsa-sha256; cv=none; b=FwyO+P4bqUZm4oHCH5jAvKiXib3QPu86NZAfuXgsdK1FQXEjV/lece37A5G8BdirIOgUoq hEOCcydqcK2oyzSXUjClCLYw/Y4nBPwEHTxr8GJbbkePy/cvoIZX//tDeojWNJdPwNtWke 938JC6O4PZbk4RcvQ6PcBs45UTyR7eSmdSwC2gwtqBoSY+y567Rp/0YtJlhsG3Go2lPsYX cIMIF85M1FkO4IOambHYfeQ5Qki2wXGrU0TW0mecmve9ZMTdl9LqTfW1Uw/9Z4XkiF7hrq fATDoo3LzwyvW8yb9mCy34SwjbzEdjwx/AVKX3g8by+XpF5MaFjtrIyEniBnVA== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=hlinnaka smtp.mailfrom=hlinnaka@iki.fi ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1709827716; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CX3BcC7AzVsYM75tq6Nhb88LgDGsmW1NCUeBnEyNTzU=; b=h+U0UUPbaR+jPUwtDchgoItF7Yj5GBoqEC0yfeHO1eKgmBq2hSGZ1LLajuMBSMldM2i73n 0GtDN7+5Z9oP4XrQmWHASocxFWNDK5JIYZ76uduneTFnesCZd0Mg5cEBnFgIrchiT8yMxt uQ3KR2EHUkXhUcmk+VaMqCMqB7KzPR8QvW2FrmRsHftFF2ogiGTm1bjMSC9TsUepIeFPgh 34ilLbAxoD4PP9aVn1EZcTJ22qhzhNr0yBYoDkJLJu7hqJpz2kaVfnPK3sU20Uaqhi222V JopInVxQvU2er+Nz7Y6IZ/yrOGhcs6fnJqA4DM+CIqrOOxkDyZ/JZx7bqbWHvQ== Message-ID: <86932ed6-e4b3-44cd-abf2-7f0173dea782@iki.fi> Date: Thu, 7 Mar 2024 18:08:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: improve ssl error code, 2147483650 Content-Language: en-US To: David Zhang , Pgsql Hackers References: From: Heikki Linnakangas In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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)