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.
>
>
> cheers
>
>
> andrew
>
>
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services