On 10/31/19 6:34 PM, Andrew Dunstan wrote: > This time with attachment. > > > On 10/31/19 6:33 PM, Andrew Dunstan wrote: >> This patch provides for an sslpassword parameter for libpq, and a hook >> that a client can fill in for a callback function to set the password. >> >> >> This provides similar facilities to those already available in the JDBC >> driver. >> >> >> There is also a function to fetch the sslpassword from the connection >> parameters, in the same way that other settings can be fetched. >> >> >> This is mostly the excellent work of my colleague Craig Ringer, with a >> few embellishments from me. >> >> >> Here are his notes: >> >> >> Allow libpq to non-interactively decrypt client certificates that >> are stored >> encrypted by adding a new "sslpassword" connection option. >> >> The sslpassword option offers a middle ground between a cleartext >> key and >> setting up advanced key mangement via openssl engines, PKCS#11, USB >> crypto >> offload and key escrow, etc. >> >> Previously use of encrypted client certificate keys only worked if >> the user >> could enter the key's password interactively on stdin, in response >> to openssl's >> default prompt callback: >> >> Enter PEM passhprase: >> >> That's infesible in many situations, especially things like use from >> postgres_fdw. >> >> This change also allows admins to prevent libpq from ever prompting >> for a >> password by calling: >> >> PQsetSSLKeyPassHook(PQdefaultSSLKeyPassHook); >> >> which is useful since OpenSSL likes to open /dev/tty to prompt for a >> password, >> so even closing stdin won't stop it blocking if there's no user >> input available. >> Applications may also override or extend SSL password fetching with >> their own >> callback. >> >> There is deliberately no environment variable equivalent for the >> sslpassword >> option. >> >>
I should also mention that this patch provides for support for DER format certificates and keys.
Yep, that was a trivial change I rolled into it.
FWIW, this is related to two other patches: the patch to allow passwordless fdw connections with explicit superuser approval, and the patch to allow sslkey/sslpassword to be set as user mapping options in postgres_fdw . Together all three patches make it possible to use SSL client certificates to manage authentication in postgres_fdw user mappings.
