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 02260088-E0C9-49A2-ACD3-CE51D65A84E3@yesql.se
Whole thread Raw
In response to Re: Support for NSS as a libpq TLS backend  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Support for NSS as a libpq TLS backend  (Jacob Champion <pchampion@vmware.com>)
List pgsql-hackers
> On 27 Oct 2020, at 21:18, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>
> On 27/10/2020 22:07, Daniel Gustafsson wrote:
>> /*
>> * Track whether the NSS database has a password set or not. There is no API
>> * function for retrieving password status, so we simply flip this to true in
>> * case NSS invoked the password callback - as that will only happen in case
>> * there is a password. The reason for tracking this is that there are calls
>> * which require a password parameter, but doesn't use the callbacks provided,
>> * so we must call the callback on behalf of these.
>> */
>> static bool has_password = false;
>
> This is set in PQssl_passwd_cb function, but never reset. That seems wrong. The NSS database used in one connection
mighthave a password, while another one might not. Or have I completely misunderstood this? 

(sorry for slow response).  You are absolutely right, the has_password flag
must be tracked per connection in PGconn.  The attached v17 implements this as
well a frontend bugfix which caused dropped connections and some smaller fixups
to make strings more translateable.

I've also included a WIP version of SCRAM channel binding in the attached
patch, it's currently failing to connect but someone here might spot the bug
before I do so I figured it's better to include it.

The 0005 patch is now, thanks to the sslinfo patch going in on master, only
containing NSS specific code.

cheers ./daniel


Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: hash_array_extended() needs to pass down collation
Next
From: Daniel Gustafsson
Date:
Subject: Re: Support for NSS as a libpq TLS backend