Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256 - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
Date
Msg-id 89cbbbf1-4c92-48bd-7d37-e3a31ec09af5@2ndquadrant.com
Whole thread Raw
In response to Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
List pgsql-hackers
On 1/4/18 15:41, Peter Eisentraut wrote:
> On 12/28/17 02:19, Michael Paquier wrote:
>> On Wed, Dec 27, 2017 at 09:27:40AM +0900, Michael Paquier wrote:
>>> On Tue, Dec 26, 2017 at 03:28:09PM -0500, Peter Eisentraut wrote:
>>>> On 12/22/17 03:10, Michael Paquier wrote:
>>>>> Second thoughts on 0002 as there is actually no need to move around
>>>>> errorMessage if the PGconn* pointer is saved in the SCRAM status data
>>>>> as both are linked. The attached simplifies the logic even more.
>>>>>
>>>>
>>>> That all looks pretty reasonable.
>>>
>>> Thanks for the review. Don't you think that the the refactoring
>>> simplifications should be done first though? This would result in
>>> producing the patch set in reverse order. I'll be fine to produce them
>>> if need be.
>>
>> Well, here is a patch set doing the reverse operation: refactoring does
>> first in 0001 and support for tls-server-end-point is in 0002. Hope this
>> helps.
> 
> committed

Some hosts don't seem to have X509_get_signature_nid().  Looking into
that ...

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Condition variable live lock
Next
From: Tom Lane
Date:
Subject: Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256