Re: Support for NSS as a libpq TLS backend

On Wed, Nov 10, 2021 at 8:49 AM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
> > On 9 Nov 2021, at 22:22, Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com> wrote:
> > On Tue, Nov 9, 2021 at 2:02 PM Joshua Brindle
> > <joshua(dot)brindle(at)crunchydata(dot)com> wrote:
> >>
> >> On Tue, Nov 9, 2021 at 1:59 PM Joshua Brindle
> >> <joshua(dot)brindle(at)crunchydata(dot)com> wrote:
>
> >>> Hello, I'm looking to help out with reviews for this CF and I'm
> >>> currently looking at this patchset.
>
> Thanks, much appreciated!
>
> >>> currently I'm stuck trying to configure:
> >>>
> >>> checking for nss-config... /usr/bin/nss-config
> >>> checking for nspr-config... /usr/bin/nspr-config
> >>> ...
> >>> checking nss/ssl.h usability... no
> >>> checking nss/ssl.h presence... no
> >>> checking for nss/ssl.h... no
> >>> configure: error: header file <nss/ssl.h> is required for NSS
> >>>
> >>> This is on fedora 33 and nss-devel is installed, nss-config is
> >>> available (and configure finds it) but the directory is different from
> >>> Ubuntu:
> >>> (base) [vagrant(at)fedora ~]$ nss-config --includedir
> >>> /usr/include/nss3
> >>> (base) [vagrant(at)fedora ~]$ ls -al /usr/include/nss3/ssl.h
> >>> -rw-r--r--. 1 root root 70450 Sep 30 05:41 /usr/include/nss3/ssl.h
> >>>
> >>> So if nss-config --includedir is used then #include <ssl.h> should be
> >>> used, or if not then #include <nss3/ssl.h> but on this system #include
> >>> <nss/ssl.h> is not going to work.
>
> Interesting rename, I doubt any version but NSS 3 and NSPR 4 is alive anywhere
> and an incremented major version seems highly unlikely. Going back to plain
> #include <ssl.h> and have the includeflags sort out the correct directories
> seems like the best option then. Fixed in the attached.
>
> >> FYI, if I make a symlink to get past this, configure completes but
> >> compilation fails because nspr/nspr.h cannot be found (I'm not sure
> >> why configure doesn't discover this)
> >> ../../src/include/common/nss.h:31:10: fatal error: 'nspr/nspr.h' file not found
> >> #include <nspr/nspr.h>In file included from protocol_nss.c:24:
> >> ../../src/include/common/nss.h:31:10: fatal error: 'nspr/nspr.h' file not found
> >> #include <nspr/nspr.h>
> >> ^~~~~~~~~~~~~
> >>
> >> It's a similar issue:
> >> $ nspr-config --includedir
> >> /usr/include/nspr4
>
> Fixed.
>
> > If these get resolved the next issue is llvm bitcode doesn't compile
> > because the nss includedir is missing from CPPFLAGS:
> >
> > /usr/bin/clang -Wno-ignored-attributes -fno-strict-aliasing -fwrapv
> > -O2 -I../../../src/include -D_GNU_SOURCE -I/usr/include/libxml2
> > -I/usr/include -flto=thin -emit-llvm -c -o be-secure-nss.bc
> > be-secure-nss.c
> > In file included from be-secure-nss.c:20:
> > In file included from ../../../src/include/common/nss.h:38:
> > In file included from /usr/include/nss/nss.h:34:
> > /usr/include/nss/seccomon.h:17:10: fatal error: 'prtypes.h' file not found
> > #include "prtypes.h"
> > ^~~~~~~~~~~
> > 1 error generated.
>
> Fixed.

Apologies for the delay, this didn't go to my inbox and I missed it on list.

The bitcode generation is still broken, this time for nspr.h:

/usr/bin/clang -Wno-ignored-attributes -fno-strict-aliasing -fwrapv
-O2 -I../../../src/include -D_GNU_SOURCE -I/usr/include/libxml2
-I/usr/include -flto=thin -emit-llvm -c -o be-secure-nss.bc
be-secure-nss.c
In file included from be-secure-nss.c:20:
../../../src/include/common/nss.h:31:10: fatal error: 'nspr.h' file not found
#include <nspr.h>
^~~~~~~~
1 error generated.

FWIW I attached the Dockerfile I've been using to test this, primarily
to ensure that there were no openssl devel files lurking around during
compilation.

It expects a ./postgres directory with whatever patches already applied to it.

>
> The attached also resolves the conflicts in pgcrypto following db7d1a7b05. PGP
> elgamel and RSA pubkey functions aren't supported for now as there is no bignum
> functions similar to the BN_* in OpenSSL. I will look into more how hard it
> would be to support, for now this gets us ahead.
>
> --
> Daniel Gustafsson https://vmware.com/
>