Re: Password identifiers, protocol aging and SCRAM protocol
От | Stephen Frost |
---|---|
Тема | Re: Password identifiers, protocol aging and SCRAM protocol |
Дата | |
Msg-id | 20160706225141.GM21416@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: Password identifiers, protocol aging and SCRAM protocol (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Password identifiers, protocol aging and SCRAM protocol
|
Список | pgsql-hackers |
* Michael Paquier (michael.paquier@gmail.com) wrote: > On Tue, Jul 5, 2016 at 5:50 PM, Magnus Hagander <magnus@hagander.net> wrote: > > On Tue, Jul 5, 2016 at 10:06 AM, Michael Paquier <michael.paquier@gmail.com> wrote: > > However, is there something that's fundamentally better with the OpenSSL > > implementation? Or should we just keep *just* the #else branch in the code, > > the part we've imported from OpenBSD? > > Good question. I think that we want both, giving priority to OpenSSL > if it is there. Usually their things prove to have more entropy, but I > didn't look at their code to be honest. If we only use the OpenBSD > stuff, it would be a good idea to refresh the in-core code. This is > from OpenBSD of 2002. I agree that we definitely want to use the OpenSSL functions when they are available. > > I'm not sure how common a build without openssl is in the real world though. > > RPMs, DEBs, Windows installers etc all build with OpenSSL. But we probably > > don't want to make it mandatory, no... > > I don't think that it is this much common to have an enterprise-class > build of Postgres without SSL, but each company has always its own > reasons, so things could exist. I agree that it's useful to have the support if PG isn't built with OpenSSL for some reason. Thanks! Stephen
В списке pgsql-hackers по дате отправления: