From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Subject: | Re: Support for NSS as a libpq TLS backend |
Date: | 2020-11-01 22:04:18 |
Message-ID: | 977041A2-0103-4150-8174-FB77F6C238A2@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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?
Being well versed in the buildfarm code, do you have an off-the-cuff idea on
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.
> I also notice that the invocations to pk12util don't contain the "sql:"
> prefix to the -d option, even though the database was created with that
> prefix a few lines above. That seems like a mistake from my reading of
> the pk12util man page.
Fixed in the attached v16, which also drops the parts of the patchset which
have been submitted separately to -hackers (the sslinfo patch hunks are still
there are they are required).
cheers ./daniel
Attachment | Content-Type | Size |
---|---|---|
v16-0001-NSS-Frontend-Backend-and-build-infra.patch | application/octet-stream | 103.7 KB |
v16-0002-NSS-Testharness-updates.patch | application/octet-stream | 49.3 KB |
v16-0003-NSS-pg_strong_random-support.patch | application/octet-stream | 4.1 KB |
v16-0004-NSS-Documentation.patch | application/octet-stream | 14.2 KB |
v16-0005-NSS-contrib-modules.patch | application/octet-stream | 34.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2020-11-01 23:02:19 | Re: how to replicate test results in cf-bot on travis |
Previous Message | Tom Lane | 2020-11-01 20:47:45 | Getting rid of aggregate_dummy() |