Re: Support for NSS as a libpq TLS backend

On 11/1/20 5:04 PM, Daniel Gustafsson wrote:
>> On 1 Nov 2020, at 14:13, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> I've been looking through the new patch set, in particular the testing
>> setup.
> Thanks!
>
>> The way it seems to proceed is to use the existing openssl generated
>> certificates and imports them into NSS certificate databases. That seems
>> fine to bootstrap testing,
> That's pretty much why I opted for using the existing certs: to bootstrap the
> patch and ensure OpenSSL-backend compatibility.
>
>> but it seems to me it would be more sound not
>> to rely on openssl at all. I'd rather see the Makefile containing
>> commands to create these from scratch, which mirror the openssl
>> variants. IOW you should be able to build and test this from scratch,
>> including certificate generation, without having openssl installed at all.
> I don't disagree with this, but I do also believe there is value in testing all
> TLS backends with exactly the same certificates to act as a baseline. The
> nssfiles target should definitely be able to generate from scratch, but maybe a
> combination is the best option?

Yeah. I certainly think we need something that should how we would
generate them from scratch using nss. That said, the importation code is
also useful.

>
> Being well versed in the buildfarm code, do you have an off-the-cuff idea onIU
> how to do cross library testing such that OpenSSL/NSS compatibility can be
> ensured? Andres was floating the idea of making a single sourcetree be able to
> have both for testing but more discussion is needed to settle on a way forward.

Well, I'd probably try to leverage the knowledge we have in doing
cross-version upgrade testing. It works like this: After the
install-check-C stage each branch saves its binaries and data files in a
special location, adjusting things like library locations to match. then
to test that version it uses that against all the older versions
similarly saved.

We could generalize that saving mechanism and do it if any module
required it. But instead of testing against a different branch, we'd
test against a different animal. So we'd have two animals, one building
with openssl and one with nss, and they would test against each other
(i.e. one as the client and one as the sever, and vice versa).

This would involve a deal of work on my part, but it's very doable, I
believe.

We'd need a way to run tests where we could specify the client and
server binary locations.

Anyway, those are my thoughts. Comments welcome.

cheers

andrew

--
Andrew Dunstan
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company