On Tue, 2021-03-23 at 00:38 +0100, Daniel Gustafsson wrote: > This rebase also includes a fix for pgtls_init which was sent offlist by > Jacob. > The changes in pgtls_init can potentially be used to initialize the crypto > context for NSS to clean up this patch, Jacob is currently looking at that.
I'm having a hell of a time trying to get the context stuff working. Findings so far (I have patches in progress for many of these, but it's all blowing up because of the last problem): NSS_INIT_NOROOTINIT is hardcoded for NSS_InitContext(), so we probably don't need to pass it explicitly. NSS_INIT_PK11RELOAD is apparently meant to hack around libraries that do their own PKCS loading; do we need it? NSS_ShutdownContext() can (and does) fail if we've leaked handles to objects, so we need to check its return value. Once this happens, future NSS_InitContext() calls behave poorly. Currently we leak the pr_fd as well as a handful of server_cert handles. NSS_NoDB_Init() is going to pin NSS in memory. For the backend this is probably okay, but for libpq clients that's probably not what we want. The first database loaded by NSS_InitContext() becomes the "default" database. This is what I'm currently hung up on. I can't figure out how to get NSS to use the database that was loaded for the current connection, so in my local patches for the issues above, client certificates fail to load. 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? --Jacob
