Re: Support for NSS as a libpq TLS backend
От | Stephen Frost |
---|---|
Тема | Re: Support for NSS as a libpq TLS backend |
Дата | |
Msg-id | 20210324170036.GS20766@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: Support for NSS as a libpq TLS backend (Jacob Champion <pchampion@vmware.com>) |
Ответы |
Re: Support for NSS as a libpq TLS backend
|
Список | pgsql-hackers |
Greetings Jacob, * Jacob Champion (pchampion@vmware.com) wrote: > On Wed, 2021-03-24 at 09:28 +0900, Michael Paquier wrote: > > On Wed, Mar 24, 2021 at 12:05:35AM +0000, Jacob Champion wrote: > > > I can work around it temporarily for the > > > tests, but this will be a problem if any libpq clients load up multiple > > > independent databases for use with separate connections. Anyone know if > > > this is a supported use case for NSS? > > > > Are you referring to the case of threading here? This should be a > > supported case, as threads created by an application through libpq > > could perfectly use completely different connection strings. > Right, but to clarify -- I was asking if *NSS* supports loading and > using separate certificate databases as part of its API. It seems like > the internals make it possible, but I don't see the public interfaces > to actually use those internals. Yes, this is done using SECMOD_OpenUserDB, see: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/PKCS11_Functions#SECMOD_OpenUserDB also there's info here: https://groups.google.com/g/mozilla.dev.tech.crypto/c/Xz6Emfcue0E We should document that, as mentioned in the link above, the NSS find functions will find certs in all the opened databases. As this would all be under one application which is linked against libpq and passing in different values for ssl_database for different connections, this doesn't seem like it's really that much of an issue. Thanks! Stephen
Вложения
В списке pgsql-hackers по дате отправления: