|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||Daniel Gustafsson <daniel(at)yesql(dot)se>|
|Cc:||Stephen Frost <sfrost(at)snowman(dot)net>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Jacob Champion <pchampion(at)vmware(dot)com>, "hlinnaka(at)iki(dot)fi" <hlinnaka(at)iki(dot)fi>, "andrew(dot)dunstan(at)2ndquadrant(dot)com" <andrew(dot)dunstan(at)2ndquadrant(dot)com>, "thomas(dot)munro(at)gmail(dot)com" <thomas(dot)munro(at)gmail(dot)com>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>|
|Subject:||Re: Support for NSS as a libpq TLS backend|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Mon, Apr 05, 2021 at 11:12:22AM +0900, Michael Paquier wrote:
> Please find an updated set, v35, attached, and my apologies for
> breaking again your patch set. While testing this patch set and
> adjusting the SSL tests with HEAD, I have noticed what looks like a
> bug with the DN mapping that NSS does not run. The connection strings
> are the same in v35 and in v34, with dbname only changing in-between.
> Just to be sure, because I could have done something wrong with the
> rebase of v35, I have done the same test with v34 applied on top of
> dfc843d and things are failing. So it seems to me that there is an
> issue with the DN mapping part.
For now, I have marked this patch set as returned with feedback as it
is still premature for integration, and there are still bugs in it.
FWIW, I think that there is a future for providing an alternative to
OpenSSL, so, even if it could not make it for this release, I'd like
to push forward with this area more seriously as of 15. The recent
libcrypto-related refactorings were one step in this direction, as
|Next Message||Magnus Hagander||2021-04-08 08:30:53||Re: pg_stat_statements oddity with track = all|
|Previous Message||Michael Paquier||2021-04-08 08:04:35||Re: PATCH: Attempt to make dbsize a bit more consistent|