Обсуждение: lippq client library and openssl initialization: PQinitOpenSSL()
Hello!
The PostgreSQL doc says that if the application code is initializing OpenSSL, it should tell PostgreSQL libpq client library that OpenSSL initialization is already done:
I was wondering if this is still true with OpenSSL 1.1.0+
The APIs to initialize OpenSSL are OPENSSL_init_ssl() or OPENSSL_init_crypto().
According to the OpenSSL doc, version 1.1.0 initializes itself automatically when calling other APIs ...
As of version 1.1.0 OpenSSL will automatically allocate all resources that it needs so no explicit initialisation is required. Similarly it will also automatically deinitialise as required.
So, is a call to PQinitOpenSSL(0, 0) still needed?
I did some test with our application, and I could establish a TLS/SSL connection using server and client certificates.
What can go wrong in fact?
Can someone give me a hint, so I can prove that we really need to call PQinitOpenSSL(0,0)?
Note: Our application is for now single-threaded.
OpenSSL doc also states:
However, there may be situations when explicit initialisation is desirable or needed, for example when some nondefault initialisation is required.
If our application would requires nondefault initialization, I assume that PostgreSQL openssl usage will implicitly inherit the OpenSSL seetings of our application, right?
Can this be an issue for PostgreSQL, or can both just share the same OpenSSL settings/config?
Thanks!
Seb
On Sun, Sep 11, 2022 at 6:55 AM Sebastien Flaesch <sebastien.flaesch@4js.com> wrote: > > The PostgreSQL doc says that if the application code is initializing OpenSSL, it should tell PostgreSQL libpq client librarythat OpenSSL initialization is already done: > > https://www.postgresql.org/docs/14/libpq-ssl.html#LIBPQ-SSL-INITIALIZE > > I was wondering if this is still true with OpenSSL 1.1.0+ > > The APIs to initialize OpenSSL are OPENSSL_init_ssl() or OPENSSL_init_crypto(). > > According to the OpenSSL doc, version 1.1.0 initializes itself automatically when calling other APIs ... > > https://www.openssl.org/docs/man1.1.1/man3/OPENSSL_init_ssl.html > > As of version 1.1.0 OpenSSL will automatically allocate all resources that it needs so no explicit initialisation is required.Similarly it will also automatically deinitialise as required. > > So, is a call to PQinitOpenSSL(0, 0) still needed? > > I did some test with our application, and I could establish a TLS/SSL connection using server and client certificates. > > What can go wrong in fact? > > Can someone give me a hint, so I can prove that we really need to call PQinitOpenSSL(0,0)? > > Note: Our application is for now single-threaded. > > OpenSSL doc also states: > > However, there may be situations when explicit initialisation is desirable or needed, for example when some nondefaultinitialisation is required. > > If our application would requires nondefault initialization, I assume that PostgreSQL openssl usage will implicitly inheritthe OpenSSL seetings of our application, right? > > Can this be an issue for PostgreSQL, or can both just share the same OpenSSL settings/config? For the OpenSSL side of things, then see https://wiki.openssl.org/index.php/Library_Initialization . Jeff
Sebastien Flaesch <sebastien.flaesch@4js.com> writes: > The PostgreSQL doc says that if the application code is initializing OpenSSL, it should tell PostgreSQL libpq client librarythat OpenSSL initialization is already done: > https://www.postgresql.org/docs/14/libpq-ssl.html#LIBPQ-SSL-INITIALIZE > I was wondering if this is still true with OpenSSL 1.1.0+ Don't believe so. The HAVE_CRYPTO_LOCK stuff is all obsolete and not compiled if you built against 1.1.0. The only thing left that will happen if you don't call PQinitOpenSSL is an extra call to OPENSSL_init_ssl, which should be harmless as far as I can see from the OpenSSL docs. regards, tom lane
> On 11 Sep 2022, at 17:08, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Sebastien Flaesch <sebastien.flaesch@4js.com> writes: >> The PostgreSQL doc says that if the application code is initializing OpenSSL, it should tell PostgreSQL libpq client librarythat OpenSSL initialization is already done: >> https://www.postgresql.org/docs/14/libpq-ssl.html#LIBPQ-SSL-INITIALIZE >> I was wondering if this is still true with OpenSSL 1.1.0+ > > Don't believe so. The HAVE_CRYPTO_LOCK stuff is all obsolete and > not compiled if you built against 1.1.0. The only thing left that > will happen if you don't call PQinitOpenSSL is an extra call to > OPENSSL_init_ssl, which should be harmless as far as I can see > from the OpenSSL docs. To the best of my knowledge, thats entirely correct. -- Daniel Gustafsson https://vmware.com/
Daniel Gustafsson <daniel@yesql.se> writes:
> On 11 Sep 2022, at 17:08, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Don't believe so. The HAVE_CRYPTO_LOCK stuff is all obsolete and
>> not compiled if you built against 1.1.0. The only thing left that
>> will happen if you don't call PQinitOpenSSL is an extra call to
>> OPENSSL_init_ssl, which should be harmless as far as I can see
>> from the OpenSSL docs.
> To the best of my knowledge, thats entirely correct.
Should we document these functions as obsolete when using
OpenSSL >= 1.1.0 ?
regards, tom lane
> On 11 Sep 2022, at 23:35, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Daniel Gustafsson <daniel@yesql.se> writes: >> On 11 Sep 2022, at 17:08, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Don't believe so. The HAVE_CRYPTO_LOCK stuff is all obsolete and >>> not compiled if you built against 1.1.0. The only thing left that >>> will happen if you don't call PQinitOpenSSL is an extra call to >>> OPENSSL_init_ssl, which should be harmless as far as I can see >>> from the OpenSSL docs. > >> To the best of my knowledge, thats entirely correct. > > Should we document these functions as obsolete when using > OpenSSL >= 1.1.0 ? Given that 1.1.0+ is very common, it's probably not a bad idea to document them as obsolete but harmless. Unless you beat me to it I can propose a patch. -- Daniel Gustafsson https://vmware.com/
On 11.09.22 23:43, Daniel Gustafsson wrote: >> On 11 Sep 2022, at 23:35, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> >> Daniel Gustafsson <daniel@yesql.se> writes: >>> On 11 Sep 2022, at 17:08, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> Don't believe so. The HAVE_CRYPTO_LOCK stuff is all obsolete and >>>> not compiled if you built against 1.1.0. The only thing left that >>>> will happen if you don't call PQinitOpenSSL is an extra call to >>>> OPENSSL_init_ssl, which should be harmless as far as I can see >>>> from the OpenSSL docs. >> >>> To the best of my knowledge, thats entirely correct. >> >> Should we document these functions as obsolete when using >> OpenSSL >= 1.1.0 ? > > Given that 1.1.0+ is very common, it's probably not a bad idea to document them > as obsolete but harmless. Unless you beat me to it I can propose a patch. AFAICT, RHEL 7 ships with an older version. I think that's still pretty widespread.
> On 12 Sep 2022, at 13:21, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote: > On 11.09.22 23:43, Daniel Gustafsson wrote: >>> On 11 Sep 2022, at 23:35, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Should we document these functions as obsolete when using >>> OpenSSL >= 1.1.0 ? >> Given that 1.1.0+ is very common, it's probably not a bad idea to document them >> as obsolete but harmless. Unless you beat me to it I can propose a patch. > > AFAICT, RHEL 7 ships with an older version. I think that's still pretty widespread. Fair enough. That doesn't however IMO prevent us from adding a note that 1.1.0 and onwards are different. The attached keeps the strong wording of the main para, but adds a note after the related functions. -- Daniel Gustafsson https://vmware.com/
Вложения
Daniel Gustafsson <daniel@yesql.se> writes:
> On 12 Sep 2022, at 13:21, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
>> AFAICT, RHEL 7 ships with an older version. I think that's still pretty widespread.
> Fair enough. That doesn't however IMO prevent us from adding a note that 1.1.0
> and onwards are different. The attached keeps the strong wording of the main
> para, but adds a note after the related functions.
Personally I'd put this up front, more like
have been initialized by your application, so that
<application>libpq</application> will not also initialize those libraries.
+ However, this is unnecessary when using OpenSSL 1.1.0 or later,
+ as duplicate initializations are no longer problematic.
</para>
If you do use wording that specifically mentions PQinitOpenSSL,
it should also mention PQinitSSL, just for clarity.
regards, tom lane
> On 12 Sep 2022, at 15:47, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Personally I'd put this up front, more like > > have been initialized by your application, so that > <application>libpq</application> will not also initialize those libraries. > + However, this is unnecessary when using OpenSSL 1.1.0 or later, > + as duplicate initializations are no longer problematic. > </para> > > If you do use wording that specifically mentions PQinitOpenSSL, > it should also mention PQinitSSL, just for clarity. Reviving an old thread that got buried, I propose to apply the attached and backpatch it as OpenSSL of such vintage is equally likely to be used in old versions of postgres as current. -- Daniel Gustafsson
Вложения
Daniel Gustafsson <daniel@yesql.se> writes:
> Reviving an old thread that got buried, I propose to apply the attached and
> backpatch it as OpenSSL of such vintage is equally likely to be used in old
> versions of postgres as current.
+1
regards, tom lane