From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
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-17 18:31:36 |
Message-ID: | CABUevExFJW+PWrWE4a1ZqKq2EeEfkcuyUQXxPhPbW-TbNGeMqQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 17, 2018 at 8:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> > On 1/17/18 12:39, Tom Lane wrote:
> >> I don't know too much about the internals here, so looking at your
> >> list, I wonder whether "ssl_dh_params_file" ought to be treated as
> >> implementation-specific too. The other four files seem essential
> >> to any feature-complete implementation, but is that one?
>
> > The proposed GnuTLS patch does make use of ssl_dh_params_file.
>
> Right, but what happens if say macTLS doesn't?
>
> There are basically two approaches we can take here:
>
> 1. All the relevant parameters are named "ssl_something", and we have
> to flag in the documentation any that are supported only by some
> implementations.
>
> 2. Parameters that might be supported only by some implementations
> are named with implementation-specific names, and we have to accept
> that there might sometimes be both "foossl_xyz" and "barssl_xyz".
>
> What I don't want to end up with is an unholy mixture of both approaches.
> Therefore, if we are going to use method #2, we must be certain that
> the basic "ssl_" parameters are supported by every implementation,
> to the point where we'd reject an implementation that didn't have one.
> I can see that we'd reject an implementation lacking CRL support
> for instance, but I'm less clear that lack of configurable DH parameters
> should be a disqualifying feature omission. I'm prepared to be educated
> either way, but that's the core question here.
>
So in this particular case, does it mean that to do #2, we sould actually
have an openssl_dh_params_file and a gnutls_dh_params_file, but only one at
any given time?
Thinking on that there is also the case of file formats. What if one
provider takes a cert file, but not in the same format -- should that still
be ssl_cert_file, or should it be a different parameter name? Given that
you can't use it to point to the same file.
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2018-01-17 18:40:14 | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) |
Previous Message | Tom Lane | 2018-01-17 18:30:20 | Re: Test-cases for exclusion constraints is missing in alter_table.sql file |