Re: Support for NSS as a libpq TLS backend

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Re: Support for NSS as a libpq TLS backend
Date: 2020-11-04 13:09:52
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On 27 Oct 2020, at 21:18, Heikki Linnakangas <hlinnaka(at)iki(dot)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 might have 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 Content-Type Size
v17-0001-NSS-Frontend-Backend-and-build-infrastructure.patch application/octet-stream 109.4 KB
v17-0002-NSS-Testharness-updates.patch application/octet-stream 49.5 KB
v17-0003-NSS-pg_strong_random-support.patch application/octet-stream 4.1 KB
v17-0004-NSS-Documentation.patch application/octet-stream 14.2 KB
v17-0005-NSS-contrib-modules.patch application/octet-stream 29.9 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2020-11-04 13:14:12 Re: Support for NSS as a libpq TLS backend
Previous Message Peter Eisentraut 2020-11-04 11:51:40 Re: hash_array_extended() needs to pass down collation