On Mon, Jan 6, 2020 at 7:02 AM Michael Paquier <mich...@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/
