| 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-04 13:14:12 |
| Message-ID: | 4069EDBF-11BF-49E4-AF18-1A859157BAEF@yesql.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 2 Nov 2020, at 15:17, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> 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).
That seems like a very good plan. It would also allow us to test a backend
compiled with OpenSSL 1.0.2 against a frontend with OpenSSL 1.1.1 which might
come in handy when OpenSSL 3.0.0 lands.
> This would involve a deal of work on my part, but it's very doable, I
> believe.
I have no experience with the buildfarm code, but I'm happy to help if theres
anything I can do.
cheers ./daniel
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2020-11-04 13:49:57 | Re: Some doubious code in pgstat.c |
| Previous Message | Daniel Gustafsson | 2020-11-04 13:09:52 | Re: Support for NSS as a libpq TLS backend |