Re: Supporting tls-server-end-point as SCRAM channel binding forOpenSSL 1.0.0 and 1.0.1
Вложения
В списке pgsql-hackers по дате отправления:
| От | Michael Paquier |
|---|---|
| Тема | Re: Supporting tls-server-end-point as SCRAM channel binding forOpenSSL 1.0.0 and 1.0.1 |
| Дата | |
| Msg-id | 20180530024820.GA19009@paquier.xyz обсуждение |
| Ответ на | Re: Supporting tls-server-end-point as SCRAM channel binding forOpenSSL 1.0.0 and 1.0.1 (Heikki Linnakangas <hlinnaka@iki.fi>) |
| Ответы |
Re: Supporting tls-server-end-point as SCRAM channel binding forOpenSSL 1.0.0 and 1.0.1
Re: Supporting tls-server-end-point as SCRAM channel binding forOpenSSL 1.0.0 and 1.0.1 |
| Список | pgsql-hackers |
On Tue, May 29, 2018 at 10:33:03PM -0400, Heikki Linnakangas wrote: > Hmm. I think Peter went through this in commits ac3ff8b1d8 and 054e8c6cdb. > If you got that working now, I suppose we could do that, but I'm actually > inclined to just stick to the current, more straightforward code, and > require OpenSSL 1.0.2 for this feature. OpenSSL 1.0.2 has been around for > several years now. It's not available on all the popular platforms and > distributions yet, but I don't want to bend over backwards to support those. I think that this mainly boils down to how much Postgres JDBC wants to get support here as some vendors can maintain oldest versions of OpenSSL for a long time. The extra code is not that much complicated by the way, still it is true that HEAD is cleaner with its simplicity. Steven, as the initial reporter, what's your take? -- Michael
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера