| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] GnuTLS support |
| Date: | 2018-01-30 04:03:23 |
| Message-ID: | 20180130040323.lxpwo4gtqebcfv3y@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2018-01-29 22:41:53 -0500, Tom Lane wrote:
> But I think a big part of the value here is to verify that we've
> cleaned up our internal APIs to the point where a different SSL/TLS
> implementation *could* be rolled underneath.
Yea, I completely agree with that.
> As part of that, we certainly want to look at gnutls. There might be
> more practical value (at least in the short term) in porting to the
> macOS or Windows native TLS stacks. But the more different libraries
> we look at in the process, the less likely we are to paint ourselves
> into a corner.
That's true. But any further development in the area is already going to
be painful with three libraries (openssl, native windows, native osx),
adding support for a fourth that doesn't buy as anything just seems to
make the situation worse.
Anyway, I'm only -0.5 on it, and I've said my spiel...
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Haribabu Kommi | 2018-01-30 04:10:12 | Re: Enhance pg_stat_wal_receiver view to display connected host |
| Previous Message | Tom Lane | 2018-01-30 03:41:53 | Re: [HACKERS] GnuTLS support |