On Mon, Jan 6, 2020 at 7:02 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Thu, Jan 02, 2020 at 09:46:44PM +0000, cary huang wrote:
> > I agree with Arthur that it makes sense to check the validity of
> > "conn->sslmaxprotocolversion" first before checking if it is larger
> > than "conn->sslminprotocolversion"
>
> Here I don't agree. Why not just let OpenSSL handle things with
> SSL_CTX_set_min_proto_version? We don't bother about that in the
> backend code for that reason on top of keeping the code more simple
> with less error handling. And things are cleaner when it comes to
> this libpq patch by giving up with the INT_MIN hack.
>
> > A small suggestion here. I see that PG server defaults TLS min
> > version to be TLSv1.2 and max version to none. So by default the
> > server accepts TLSv1.2 and above. I think on the client side, it
> > also makes sense to have the same defaults as the server.
>
> Yeah, that makes sense. Even more now that I have just removed
> support for OpenSSL 0.9.8 and 1.0.0 ;)
>
> There could be an argument to lower down the default if we count for
> backends built with OpenSSL versions older than libpq, but I am not
> ready to buy that there would be many of those.
Not having thought about it in much detail, but it's a fairly common
scenario to have a much newer version of libpq (and the platform it's
built on) than the server. E.g. a v12 libpq against a v9.6 postgres
server is very common. For example, debian based systems will
auto-upgrade your libpq, but not your server (for obvious reasons).
And it's also quite common to upgrade platforms for the application
much more frequently than the database server platform.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
