Fwd: PostgreSQL: WolfSSL support

2020-06-27 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_cal

Re: PostgreSQL: WolfSSL support

2020-06-28 Thread Felix Lechner
Hi Greg,

On Sun, Jun 28, 2020 at 6:40 AM Greg Stark  wrote:
>
> I'm more interested in a library like Amazon's

Does S2N support TLS 1.3?

https://github.com/awslabs/s2n/issues/388

Kind regards
Felix Lechner




Re: Fwd: PostgreSQL: WolfSSL support

2020-06-28 Thread Felix Lechner
Hi Tom,

On Sat, Jun 27, 2020 at 7:56 AM Tom Lane  wrote:
>
> However, judging from the caveats mentioned in the initial message,
> my inclination would be to wait awhile for wolfSSL to mature.

Please have a closer look. The library has been around since 2004 and
is popular in embedded systems. (It was previously known as cyaSSL.)
If you bought a car or an appliance in the past ten years, you may be
using it already.

wolfSSL's original claim to fame was that MySQL relied on it (I think
Oracle changed that). MariaDB still bundles an older, captive version.
The software is mature, and widely deployed.

Kind regards
Felix Lechner




Re: Fwd: PostgreSQL: WolfSSL support

2020-06-28 Thread Felix Lechner
Hi Jonah,

On Sat, Jun 27, 2020 at 12:35 PM Jonah H. Harris  wrote:
>
> Somewhere, I recall seeing an open-source OpenSSL compatibility wrapper for 
> WolfSSL. Assuming that still exists, this patch seems entirely unnecessary.

The patch uses the OpenSSL compatibility layer.

Kind regards
Felix Lechner




Re: Fwd: PostgreSQL: WolfSSL support

2020-06-28 Thread Felix Lechner
Hi Tom,

On Sat, Jun 27, 2020 at 11:52 AM Tom Lane  wrote:
>
> The configure
> script could add -I/usr/include/wolfssl (or wherever those files
> are) to CPPFLAGS instead of touching all those #includes.

That does not work well when OpenSSL's development files are
installed. I did not think a segmentation fault was a good way to make
friends.

> However, as long as
> it's available on GPL terms, I don't see a problem with it
> [wolfSSL] being one alternative.

A minimal patch against -13 is on its way.

Kind regards
Felix Lechner




[PATCH] Better cleanup in TLS tests for -13beta2

2020-06-29 Thread Felix Lechner
Hi,

This patch removes two temporary files that are not removed. In
Debian, repeated builds fail. We do not allow builds from modified
sources.

The first file was clearly an oversight. It was created separately. I
am not sure why the loop over @keys did not remove the second.

For the record, the error message from Debian is below. Lines 25-27
show the files that were left behind.

Kind regards,
Felix Lechner

lechner@4bba56c5a8a8:~/postgresql$ debuild
 dpkg-buildpackage -us -uc -ui
dpkg-buildpackage: info: source package postgresql-13
dpkg-buildpackage: info: source version 13~beta2-1
dpkg-buildpackage: info: source distribution experimental
dpkg-buildpackage: info: source changed by Christoph Berg 
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 fakeroot debian/rules clean
dh clean
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/home/lechner/postgresql'
rm -rf build
make[1]: Leaving directory '/home/lechner/postgresql'
   dh_autoreconf_clean
   dh_clean
 dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building postgresql-13 using existing
./postgresql-13_13~beta2.orig.tar.bz2
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: warning: ignoring deletion of file configure, use
--include-removal to override
dpkg-source: warning: ignoring deletion of file
src/include/pg_config.h.in, use --include-removal to override
dpkg-source: warning: ignoring deletion of file
doc/src/sgml/man-stamp, use --include-removal to override
dpkg-source: warning: ignoring deletion of file
doc/src/sgml/html-stamp, use --include-removal to override
dpkg-source: info: local changes detected, the modified files are:
 postgresql/src/test/ssl/ssl/client_tmp.key
 postgresql/src/test/ssl/ssl/client_wrongperms_tmp.key
dpkg-source: error: aborting due to unexpected upstream changes, see
/tmp/postgresql-13_13~beta2-1.diff.gy3ajb
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui failed
+++ b/src/test/ssl/t/001_ssltests.pl
@@ -544,6 +544,8 @@ test_connect_fails($common_connstr, "ssl
 	qr/SSL error/, "intermediate client certificate is missing");
 
 # clean up
+unlink("ssl/client_wrongperms_tmp.key");
+unlink("ssl/client_tmp.key");
 foreach my $key (@keys)
 {
 	unlink("ssl/${key}_tmp.key");