Re: libpq sslpassword parameter and callback function

2019-12-07 Thread Andrew Dunstan


On 12/6/19 2:57 AM, Noah Misch wrote:
> On Fri, Nov 29, 2019 at 09:27:02AM -0500, Andrew Dunstan wrote:
>> On 11/28/19 10:25 PM, Greg Nancarrow wrote:
>>> 3) Documentation for the "PQsslpassword" function should be added to the 
>>> libpq "33.2 Connection Status Functions" section.
>> I plan to commit this tomorrow.
> The PQsslpassword() function retrieves a connection parameter value, which one
> can retrieve with PQconninfo().  Since introducing PQconninfo(), we have not
> added any per-parameter accessor functions.  Would you remove PQsslpassword()?



*sigh* ok


cheers


andrew


-- 
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services





Re: libpq sslpassword parameter and callback function

2019-12-05 Thread Noah Misch
On Fri, Nov 29, 2019 at 09:27:02AM -0500, Andrew Dunstan wrote:
> On 11/28/19 10:25 PM, Greg Nancarrow wrote:
> > 3) Documentation for the "PQsslpassword" function should be added to the 
> > libpq "33.2 Connection Status Functions" section.

> I plan to commit this tomorrow.

The PQsslpassword() function retrieves a connection parameter value, which one
can retrieve with PQconninfo().  Since introducing PQconninfo(), we have not
added any per-parameter accessor functions.  Would you remove PQsslpassword()?




Re: libpq sslpassword parameter and callback function

2019-11-29 Thread Andrew Dunstan
On 11/28/19 10:25 PM, Greg Nancarrow wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world:  tested, passed
> Implements feature:   tested, passed
> Spec compliant:   tested, passed
> Documentation:tested, failed
>
> Hi Andrew,
>
> I've reviewed your "libpq sslpassword parameter and callback function" patch 
> (0001-libpq-sslpassword-der-support.patch), and only found a few minor things 
> (otherwise it looked good to me):
>
> 1) There's a few trailing white-space warnings on patch application (from 
> where you modified to skip 2 of the tests):
> git apply 0001-libpq-sslpassword-der-support.patch
> 0001-libpq-sslpassword-der-support.patch:649: trailing whitespace.
>   # so they don't hang. For now they are not performed. 
> 0001-libpq-sslpassword-der-support.patch:659: trailing whitespace.
>   
> warning: 2 lines add whitespace errors.
>
>
> 2) src/interfaces/libpq/libpq-fe.h
> The following portion of the comment should be removed.
>
> + * 2ndQPostgres extension. If you need to be compatible with unpatched libpq
> + * you must dlsym() these.
>
> 3) Documentation for the "PQsslpassword" function should be added to the 
> libpq "33.2 Connection Status Functions" section.
>
>
> I made the following notes about how/what I reviewed and tested:
>
> - Applied patch and built Postgres (--with-openssl --enable-tap-tests), 
> checked build output
> - Checked patch code modifications (format, logic, memory usage, efficiency, 
> corner cases etc.)
> - Built documentation and checked updated portions (format, grammar, details, 
> completeness etc.)
> - Checked test updates 
> - Ran updated contrib/dblink tests - confirmed all passed
> - Ran updated SSL (TAP) tests - confirmed all passed
> - Ran "make installcheck-world", as per review requirements
> - Wrote small libpq-based app to test:
>   - new APIs (PQsslpassword, PQsetSSLKeyPassHook, PQgetSSLKeyPassHook, 
> PQdefaultSSLKeyPassHook)
>   - passphrase-protected key with/without patch
>   - patch with/without new key password callack
>   - patch and certificate with/without pass phrase protection on key
>   - default callback, callback delegation
>   - PEM/DER keys
>
>


Thanks, nice thorough review.


Here's an updated patch that I think fixes all the things you mentioned.
I plan to commit this tomorrow.


cheers


andrew


-- 
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

>From 88913953b631b7efd5a42e2cfcb209f631c6ac5c Mon Sep 17 00:00:00 2001
From: Andrew Dunstan 
Date: Fri, 29 Nov 2019 09:21:48 -0500
Subject: [PATCH] libpq sslpassword + der support

---
 contrib/dblink/expected/dblink.out|   2 +-
 doc/src/sgml/libpq.sgml   | 134 ++
 doc/src/sgml/postgres-fdw.sgml|   2 +-
 src/interfaces/libpq/exports.txt  |   4 +
 src/interfaces/libpq/fe-connect.c |  14 +++
 src/interfaces/libpq/fe-secure-openssl.c  |  99 +++-
 src/interfaces/libpq/libpq-fe.h   |   9 ++
 src/interfaces/libpq/libpq-int.h  |   2 +
 src/test/ssl/Makefile |  22 +++-
 src/test/ssl/ssl/client-der.key   | Bin 0 -> 1191 bytes
 src/test/ssl/ssl/client-encrypted-der.key | Bin 0 -> 1191 bytes
 src/test/ssl/ssl/client-encrypted-pem.key |  30 +
 src/test/ssl/t/001_ssltests.pl|  75 ++--
 13 files changed, 376 insertions(+), 17 deletions(-)
 create mode 100644 src/test/ssl/ssl/client-der.key
 create mode 100644 src/test/ssl/ssl/client-encrypted-der.key
 create mode 100644 src/test/ssl/ssl/client-encrypted-pem.key

diff --git a/contrib/dblink/expected/dblink.out b/contrib/dblink/expected/dblink.out
index 6ceabb453c..6516d4f131 100644
--- a/contrib/dblink/expected/dblink.out
+++ b/contrib/dblink/expected/dblink.out
@@ -879,7 +879,7 @@ $d$;
 CREATE USER MAPPING FOR public SERVER fdtest
   OPTIONS (server 'localhost');  -- fail, can't specify server here
 ERROR:  invalid option "server"
-HINT:  Valid options in this context are: user, password
+HINT:  Valid options in this context are: user, password, sslpassword
 CREATE USER MAPPING FOR public SERVER fdtest OPTIONS (user :'USER');
 GRANT USAGE ON FOREIGN SERVER fdtest TO regress_dblink_user;
 GRANT EXECUTE ON FUNCTION dblink_connect_u(text, text) TO regress_dblink_user;
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 8c657d2d8d..5a48c39b56 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -776,6 +776,72 @@ PGPing PQping(const char *conninfo);
  
 
 
+
+ PQsetSSLKeyPassHookPQsetSSLKeyPassHook
+ 
+  
+   PQsetSSLKeyPassHook lets an application override
+ 

Re: libpq sslpassword parameter and callback function

2019-11-28 Thread Greg Nancarrow
The following review has been posted through the commitfest application:
make installcheck-world:  tested, passed
Implements feature:   tested, passed
Spec compliant:   tested, passed
Documentation:tested, failed

Hi Andrew,

I've reviewed your "libpq sslpassword parameter and callback function" patch 
(0001-libpq-sslpassword-der-support.patch), and only found a few minor things 
(otherwise it looked good to me):

1) There's a few trailing white-space warnings on patch application (from where 
you modified to skip 2 of the tests):
git apply 0001-libpq-sslpassword-der-support.patch
0001-libpq-sslpassword-der-support.patch:649: trailing whitespace.
# so they don't hang. For now they are not performed. 
0001-libpq-sslpassword-der-support.patch:659: trailing whitespace.

warning: 2 lines add whitespace errors.


2) src/interfaces/libpq/libpq-fe.h
The following portion of the comment should be removed.

+ * 2ndQPostgres extension. If you need to be compatible with unpatched libpq
+ * you must dlsym() these.

3) Documentation for the "PQsslpassword" function should be added to the libpq 
"33.2 Connection Status Functions" section.


I made the following notes about how/what I reviewed and tested:

- Applied patch and built Postgres (--with-openssl --enable-tap-tests), checked 
build output
- Checked patch code modifications (format, logic, memory usage, efficiency, 
corner cases etc.)
- Built documentation and checked updated portions (format, grammar, details, 
completeness etc.)
- Checked test updates 
- Ran updated contrib/dblink tests - confirmed all passed
- Ran updated SSL (TAP) tests - confirmed all passed
- Ran "make installcheck-world", as per review requirements
- Wrote small libpq-based app to test:
  - new APIs (PQsslpassword, PQsetSSLKeyPassHook, PQgetSSLKeyPassHook, 
PQdefaultSSLKeyPassHook)
  - passphrase-protected key with/without patch
  - patch with/without new key password callack
  - patch and certificate with/without pass phrase protection on key
  - default callback, callback delegation
  - PEM/DER keys


Regards,
Greg

Re: libpq sslpassword parameter and callback function

2019-11-27 Thread Andrew Dunstan

On 11/25/19 4:09 PM, Andrew Dunstan wrote:
> On 10/31/19 7:27 PM, Andrew Dunstan wrote:
>> 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.
>>
>>
>
> Here's an updated version of the patch, adjusted to the now committed
> changes to TestLib.pm.
>
>


Here's an update now we have backed out the TestLib changes. The tests
that need a pty are skipped.


cheers


andrew


-- 

Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

>From 161e1e5d4a98c075cf1aa269598db953d21bd04c Mon Sep 17 00:00:00 2001
From: Andrew Dunstan 
Date: Wed, 27 Nov 2019 18:34:55 -0500
Subject: [PATCH] libpq sslpassword + der support

---
 contrib/dblink/expected/dblink.out|   2 +-
 doc/src/sgml/libpq.sgml   | 116 ++
 doc/src/sgml/postgres-fdw.sgml|   2 +-
 src/interfaces/libpq/exports.txt  |   4 +
 src/interfaces/libpq/fe-connect.c |  14 +++
 src/interfaces/libpq/fe-secure-openssl.c  |  99 +-
 src/interfaces/libpq/libpq-fe.h   |  14 +++
 src/interfaces/libpq/libpq-int.h  |   2 +
 src/test/ssl/Makefile |  22 +++-
 src/test/ssl/ssl/client-der.key   | Bin 0 -> 1191 bytes
 src/test/ssl/ssl/client-encrypted-der.key | Bin 0 -> 1191 bytes
 src/test/ssl/ssl/client-encrypted-pem.key |  30 ++
 src/test/ssl/t/001_ssltests.pl|  75 --
 13 files changed, 363 insertions(+), 17 deletions(-)
 create mode 100644 src/test/ssl/ssl/client-der.key
 create mode 100644 src/test/ssl/ssl/client-encrypted-der.key
 create mode 100644 src/test/ssl/ssl/client-encrypted-pem.key

diff --git a/contrib/dblink/expected/dblink.out b/contrib/dblink/expected/dblink.out
index 6ceabb453c..6516d4f131 100644
--- a/contrib/dblink/expected/dblink.out
+++ b/contrib/dblink/expected/dblink.out
@@ -879,7 +879,7 @@ $d$;
 CREATE USER MAPPING FOR public SERVER fdtest
   OPTIONS (server 'localhost');  -- fail, can't specify server here
 ERROR:  invalid option "server"
-HINT:  Valid options in this context are: user, password
+HINT:  Valid options in this context are: user, password, sslpassword
 CREATE USER MAPPING FOR public SERVER fdtest OPTIONS (user :'USER');
 GRANT USAGE ON FOREIGN SERVER fdtest TO regress_dblink_user;
 GRANT EXECUTE ON FUNCTION dblink_connect_u(text, text) TO regress_dblink_user;
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 8c657d2d8d..4325946cca 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -776,6 +776,72 @@ PGPing PQping(const char *conninfo);
  
 
 
+
+ PQsetSSLKeyPassHookPQsetSSLKeyPassHook
+ 
+  
+   PQsetSSLKeyPassHook lets an application override
+   libpq's default
+   handling of encrypted client certificate key files using
+or 

Re: libpq sslpassword parameter and callback function

2019-11-25 Thread Andrew Dunstan

On 10/31/19 7:27 PM, Andrew Dunstan wrote:
> 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.
>
>


Here's an updated version of the patch, adjusted to the now committed
changes to TestLib.pm.


cheers


andrew


-- 

Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

>From b3b2104ab0a17383bb1e55ef59eaa609a417ed40 Mon Sep 17 00:00:00 2001
From: Andrew Dunstan 
Date: Mon, 25 Nov 2019 14:59:05 -0500
Subject: [PATCH] libpq sslpassword and DER support

---
 contrib/dblink/expected/dblink.out|   2 +-
 doc/src/sgml/libpq.sgml   | 116 ++
 doc/src/sgml/postgres-fdw.sgml|   2 +-
 src/interfaces/libpq/exports.txt  |   4 +
 src/interfaces/libpq/fe-connect.c |  14 +++
 src/interfaces/libpq/fe-secure-openssl.c  |  99 +-
 src/interfaces/libpq/libpq-fe.h   |  14 +++
 src/interfaces/libpq/libpq-int.h  |   2 +
 src/test/ssl/Makefile |  22 +++-
 src/test/ssl/ssl/client-der.key   | Bin 0 -> 1191 bytes
 src/test/ssl/ssl/client-encrypted-der.key | Bin 0 -> 1191 bytes
 src/test/ssl/ssl/client-encrypted-pem.key |  30 ++
 src/test/ssl/t/001_ssltests.pl|  66 ++--
 13 files changed, 354 insertions(+), 17 deletions(-)
 create mode 100644 src/test/ssl/ssl/client-der.key
 create mode 100644 src/test/ssl/ssl/client-encrypted-der.key
 create mode 100644 src/test/ssl/ssl/client-encrypted-pem.key

diff --git a/contrib/dblink/expected/dblink.out b/contrib/dblink/expected/dblink.out
index 6ceabb453c..6516d4f131 100644
--- a/contrib/dblink/expected/dblink.out
+++ b/contrib/dblink/expected/dblink.out
@@ -879,7 +879,7 @@ $d$;
 CREATE USER MAPPING FOR public SERVER fdtest
   OPTIONS (server 'localhost');  -- fail, can't specify server here
 ERROR:  invalid option "server"
-HINT:  Valid options in this context are: user, password
+HINT:  Valid options in this context are: user, password, sslpassword
 CREATE USER MAPPING FOR public SERVER fdtest OPTIONS (user :'USER');
 GRANT USAGE ON FOREIGN SERVER fdtest TO regress_dblink_user;
 GRANT EXECUTE ON FUNCTION dblink_connect_u(text, text) TO regress_dblink_user;
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 258b09cf8e..6082b38e9e 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -776,6 +776,72 @@ PGPing PQping(const char *conninfo);
  
 
 
+
+ PQsetSSLKeyPassHookPQsetSSLKeyPassHook
+ 
+  
+   PQsetSSLKeyPassHook lets an application override
+   libpq's default
+   handling of encrypted client certificate key files using
+or interactive prompting.
+
+
+void PQsetSSLKeyPassHook(PQsslKeyPassHook_type hook);
+
+
+   The application passes a pointer to a callback function with signature:
+   
+   int callback_fn(char *buf, int size, 

Re: libpq sslpassword parameter and callback function

2019-11-12 Thread Bruce Momjian
On Sun, Nov 10, 2019 at 05:47:24PM +0800, Craig Ringer wrote:
> 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.

Oh, nice, greatly needed!

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+  Ancient Roman grave inscription +




Re: libpq sslpassword parameter and callback function

2019-11-10 Thread Craig Ringer
On Fri, 1 Nov 2019 at 07:27, Andrew Dunstan 
wrote:

>
> 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.


-- 
 Craig Ringer   http://www.2ndQuadrant.com/
 2ndQuadrant - PostgreSQL Solutions for the Enterprise


Re: libpq sslpassword parameter and callback function

2019-10-31 Thread Andrew Dunstan


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.


cheers


andrew


-- 
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services





Re: libpq sslpassword parameter and callback function

2019-10-31 Thread Andrew Dunstan

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

diff --git a/contrib/dblink/expected/dblink.out b/contrib/dblink/expected/dblink.out
index 6ceabb453c..6516d4f131 100644
--- a/contrib/dblink/expected/dblink.out
+++ b/contrib/dblink/expected/dblink.out
@@ -879,7 +879,7 @@ $d$;
 CREATE USER MAPPING FOR public SERVER fdtest
   OPTIONS (server 'localhost');  -- fail, can't specify server here
 ERROR:  invalid option "server"
-HINT:  Valid options in this context are: user, password
+HINT:  Valid options in this context are: user, password, sslpassword
 CREATE USER MAPPING FOR public SERVER fdtest OPTIONS (user :'USER');
 GRANT USAGE ON FOREIGN SERVER fdtest TO regress_dblink_user;
 GRANT EXECUTE ON FUNCTION dblink_connect_u(text, text) TO regress_dblink_user;
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index c58527b0c3..a606680182 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -776,6 +776,72 @@ PGPing PQping(const char *conninfo);
  
 
 
+
+ PQsetSSLKeyPassHookPQsetSSLKeyPassHook
+ 
+  
+   PQsetSSLKeyPassHook lets an application override
+   libpq's default
+   handling of encrypted client certificate key files using
+or interactive prompting.
+
+
+void PQsetSSLKeyPassHook(PQsslKeyPassHook_type hook);
+
+
+   The application passes a pointer to a callback function with signature:
+   
+   int callback_fn(char *buf, int size, PGconn *conn);
+   
+   which libpq will then call instead of
+   its default PQdefaultSSLKeyPassHook handler. The callback
+   should determine the password for the key and copy it to result-buffer
+   buf of size size. The string in 
+   buf must be null-terminated. The calback must return the length of
+   the password stored in buf excluding the null terminator.
+   On failure, the callback should set buf[0] = '\0' and return 0.
+   See PQdefaultSSLKeyPassHook in libpq's
+   source code for an example.
+  
+   
+  
+   If the user specified an explicit key location,
+   its path will be in conn->pgsslkey when the callback
+   is invoked. This will be empty if the default key path is being used.
+   For keys that are engine specifiers, it is up to engine implementations
+   whether they use the OpenSSL password callback or define their own handling.
+  
+
+  
+   The app callback may choose to delegate unhandled cases to
+   PQdefaultSSLKeyPassHook,
+   or call it first and try something else if it returns 0, or completely override it.
+  
+
+  
+   The callback must not escape normal flow control with exceptions,
+   longjmp(...), etc. It must return normally.
+  
+
+ 
+
+
+
+ PQgetSSLKeyPassHookPQgetSSLKeyPassHook
+ 
+  
+   PQgetSSLKeyPassHook returns the current
+   client certificate key password hook, or NULL
+   if none has been set.
+
+
+PQsslKeyPassHook_type PQgetSSLKeyPassHook(void);
+
+  
+
+ 

libpq sslpassword parameter and callback function

2019-10-31 Thread Andrew Dunstan


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