Bug#963699: Fwd: PostgreSQL: WolfSSL support

2020-06-29 Thread Stephen Frost
Greetings,

* Felix Lechner (felix.lech...@lease-up.com) wrote:
> Attached please find a WIP patch for wolfSSL support in postgresql-12.

Would really be best to have this off of HEAD if we're going to be
looking at it rather than v12.  We certainly aren't going to add new
support for something new into the back-branches.

Further, I'd definitely suggest seeing how this plays with the patch to
add support for NSS which was posted recently to -hackers by Daniel.

Thanks,

Stephen


signature.asc
Description: PGP signature


Bug#963699: Fwd: PostgreSQL: WolfSSL support

2020-06-26 Thread Felix Lechner
Hi,

Is anyone here interested in helping to evaluate an experimental patch
for wolfSSL support?

Attached please find a WIP patch for wolfSSL support in postgresql-12.
As a shortcut, you may find this merge request helpful:

https://salsa.debian.org/postgresql/postgresql/-/merge_requests/4

I used Debian stable (buster) with backports enabled and preferred.

The wolfssl.patch in d/patches builds and completes all tests, as long
as libwolfssl-dev version 4.4.0+dfsg-2~bpo10+1 is installed and
patched with the included libwolfssl-dev-rename-types.patch.

You can do so as root with:

cd /usr/include/wolfssl
patch -p1 < libwolfssl-dev-rename-types.patch

Patching the library was easier than resolving type conflicts for
twenty-five files. An attempt was made but resulted in failing tests.

The offending types are called 'ValidateDate' and 'Hash'. They do not
seem to be part of the wolfSSL ABI.

The patch operates with the following caveats:

1. DH parameters are not currently loaded from a database-internal PEM
certificate. The function OBJ_find_sigid_algs is not available. The
security implications should be discussed with a cryptographer.

2. The contrib module pgcrypto was not compiled with OpenSSL support
and currently offers only native algorithms. wolfSSL's compatibility
support for OpenSSL's EVP interface is incomplete and offers only a
few algorithms. The module should work directly with wolfCrypt.

3. The error reporting in wolfSSL_set_fd seems to be different from
OpenSSL. I could not locate SSLerr and decided to return BAD_FUNC_ARG.
That is what the routine being mimicked does in wolfSSL. If you see an
SSL connection error, it may be wise to simply remove these two
statements in src/interfaces/libpq/fe-secure-openssl.c:

ret = BAD_FUNC_ARG;

Unsupported functions or features can probably be replaced with
wolfSSL's or wolfCrypt's native interfaces. The company may be happy
to assist.

The patch includes modifications toward missing goals. Some parts
modify code, for example in util/pgpcrypto, that is not actually called.

Please note that the wolfSSL team prefers the styling of their brand
to be capitalized as recorded in this sentence. Thank you!

Kind regards
Felix Lechner
unchanged:
--- a/configure.in
+++ b/configure.in
@@ -1211,7 +1211,7 @@ fi
 
 if test "$with_gssapi" = yes ; then
   if test "$PORTNAME" != "win32"; then
-AC_SEARCH_LIBS(gss_init_sec_context, [gssapi_krb5 gss 'gssapi -lkrb5 -lcrypto'], [],
+AC_SEARCH_LIBS(gss_init_sec_context, [gssapi_krb5 gss 'gssapi -lkrb5 -lwolfssl'], [],
[AC_MSG_ERROR([could not find function 'gss_init_sec_context' required for GSSAPI])])
   else
 LIBS="$LIBS -lgssapi32"
@@ -1221,29 +1221,35 @@ fi
 if test "$with_openssl" = yes ; then
   dnl Order matters!
   if test "$PORTNAME" != "win32"; then
- AC_CHECK_LIB(crypto, CRYPTO_new_ex_data, [], [AC_MSG_ERROR([library 'crypto' is required for OpenSSL])])
- AC_CHECK_LIB(ssl,SSL_new, [], [AC_MSG_ERROR([library 'ssl' is required for OpenSSL])])
+ AC_CHECK_LIB(wolfssl, wolfSSL_new, [], [AC_MSG_ERROR([library 'wolfssl' is required for OpenSSL])])
   else
- AC_SEARCH_LIBS(CRYPTO_new_ex_data, [eay32 crypto], [], [AC_MSG_ERROR([library 'eay32' or 'crypto' is required for OpenSSL])])
- AC_SEARCH_LIBS(SSL_new, [ssleay32 ssl], [], [AC_MSG_ERROR([library 'ssleay32' or 'ssl' is required for OpenSSL])])
+ AC_SEARCH_LIBS(wolfSSL_new, [wolfssl], [], [AC_MSG_ERROR([library 'wolfssl' is required for OpenSSL])])
   fi
-  AC_CHECK_FUNCS([SSL_get_current_compression X509_get_signature_nid])
+  # support for NIDs is incomplete; lack OBJ_find_sigid_algs
+  #AC_DEFINE(HAVE_X509_GET_SIGNATURE_NID, 1, [Define to 1 if you have X509_get_signature_nid()])
+
   # Functions introduced in OpenSSL 1.1.0. We used to check for
   # OPENSSL_VERSION_NUMBER, but that didn't work with 1.1.0, because LibreSSL
   # defines OPENSSL_VERSION_NUMBER to claim version 2.0.0, even though it
   # doesn't have these OpenSSL 1.1.0 functions. So check for individual
   # functions.
-  AC_CHECK_FUNCS([OPENSSL_init_ssl BIO_get_data BIO_meth_new ASN1_STRING_get0_data])
+  AC_DEFINE(HAVE_BIO_GET_DATA, 1, [Define to 1 if you have BIO_get_data()])
+
+  # support for BIO_meth_new incomplete; lack BIO_meth_get_*
+  #AC_DEFINE(HAVE_BIO_METH_NEW, 1, [Define to 1 if you have BIO_meth_new()])
+  AC_DEFINE(HAVE_ASN1_STRING_GET0_DATA, 1, [Define to 1 if you have ASN1_STRING_get0_data()])
   # OpenSSL versions before 1.1.0 required setting callback functions, for
   # thread-safety. In 1.1.0, it's no longer required, and CRYPTO_lock()
   # function was removed.
-  AC_CHECK_FUNCS([CRYPTO_lock])
+  # wolfSSL has CRYPTO_lock but does not need it; lacks CRYPTO_get_locking_callback
+  # AC_DEFINE(HAVE_CRYPTO_LOCK, 1, [Define to 1 if you have CRYPTO_lock()])
   # SSL_clear_options is a macro in OpenSSL from 0.9.8 to 1.0.2, and
   # a function from 1.1.0 onwards so we cannot use AC_CHECK_FUNCS.