Re: Support for NSS as a libpq TLS backend - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Support for NSS as a libpq TLS backend
Date
Msg-id 4C8D62D3-92C4-42EA-8102-7F24E3F8D6A2@yesql.se
Whole thread Raw
In response to Re: Support for NSS as a libpq TLS backend  (Jacob Champion <pchampion@vmware.com>)
List pgsql-hackers
> On 4 Dec 2020, at 01:57, Jacob Champion <pchampion@vmware.com> wrote:
>
> On Nov 17, 2020, at 7:00 AM, Daniel Gustafsson <daniel@yesql.se> wrote:
>>
>> Nice, thanks for the fix!  I've incorporated your patch into the attached v20
>> which also fixes client side error reporting to be more readable.
>
> I was testing handshake failure modes and noticed that some FATAL
> messages are being sent through to the client in cleartext. The OpenSSL
> implementation doesn't do this, because it logs handshake problems at
> COMMERROR level. Should we switch all those ereport() calls in the NSS
> be_tls_open_server() to COMMERROR as well (and return explicitly), to
> avoid this? Or was there a reason for logging at FATAL/ERROR level?

The ERROR logging made early development easier but then stuck around, I've
changed them to COMMERROR returning an error instead in the v21 patch just
sent to the list.

> Related note, at the end of be_tls_open_server():
>
>>    ...
>>    port->ssl_in_use = true;
>>    return 0;
>>
>> error:
>>    return 1;
>> }
>
> This needs to return -1 in the error case; the only caller of
> secure_open_server() does a direct `result == -1` comparison rather than
> checking `result != 0`.

Fixed.

cheers ./daniel


pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Support for NSS as a libpq TLS backend
Next
From: John Naylor
Date:
Subject: Re: WIP: BRIN multi-range indexes