Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
От | Peter Eisentraut |
---|---|
Тема | Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256 |
Дата | |
Msg-id | 9ac07df0-784a-cb03-a9e1-1454eca16b3b@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256 (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
|
Список | pgsql-hackers |
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 I reorganized the be_tls_get_certificate_hash() and pgtls_get_peer_certificate_hash() functions a bit to not have most of the code in a big if statement. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: