Re: Successor of MD5 authentication, let's use SCRAM

Поиск
Список
Период
Сортировка
От Daniel Farina
Тема Re: Successor of MD5 authentication, let's use SCRAM
Дата
Msg-id CAAZKuFbqQPs0jv9gPYZgrXbxoP-gG+Rd2jOh6F3UkuArduMcQQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Successor of MD5 authentication, let's use SCRAM  (Greg Stark <stark@mit.edu>)
Список pgsql-hackers
On Mon, Oct 22, 2012 at 3:54 PM, Greg Stark <stark@mit.edu> wrote:
> We could go even further:
> INFO: Server identity "ACME Debian Machine" certified by "Snakeoil CA"
> WARNING: Server identity signed by unknown and untrusted authority "Snakeoil CA"
> HINT: Add either the server certificate or the CA certificate to
> "/usr/lib/ssl/certs" after verifying the identity and certificate hash
>
> SSL is notoriously hard to set up, it would go a long way to give the
> sysadmin an immediate pointer to what certificates are being used and
> where to find or install the CA certs. It might be worth mentioning
> the GUC parameter names to control these things too.

Are the possible locations of certs that libpq reads in always so
short and definitive?  Is it clear that the user would always want to
fix the cert situation in that way?  What if they don't have file
system access to the remote database and would like to learn its
public key anyway (ala SSH trust on first use).

Overall, I do very much like the sentiment: less guesswork around
where the heck to put things or what to search for in documentation.

-- 
fdr



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [Bug] SELECT INSTEAD with sub-query
Следующее
От: Lars Kanis
Дата:
Сообщение: Failing SSL connection due to weird interaction with openssl