On Sun, Mar 04, 2018 at 11:15:58PM +0100, Daniel Gustafsson wrote: > Commitfest Status > ================= > Do I think this patch is realistic to target for v11? Well. Given where we > are in the cycle, I don’t think any new TLS implementation going in is > realistic at this point since none of the proposed ones have had enough tyre > kicking done. That might change should there be lots of interest and work > started soon, but as has been discussed elsewhere recently the project has > limited resources. I have time to work on this, and support reviewers of it, > but that’s only piece of the puzzle.
This patch has been around for some time now, and a couple of people have expressed interest in the feature, so it seems to me that there is still some room to get new features in the tree. I am not personally planning to spend much time on reviewing this specific implementation though, however... > If no new TLS library is supported in v11, we still got cleaner SSL support > out > of it due to the work performed to further remove our dependency on OpenSSL, > so > we still come out on top IMO. Thanks Peter et.al! I am definitely interested in plugging in more generic APIs for this release, so as people can also fork Postgres and implement their own SSL implementation more easily. One patch that still applies in this area is I think this one to allow SSL implementations let the backend know more easily is channel binding needs to be implemented or not: https://commitfest.postgresql.org/17/1491/ > So, TL;DR: both frontend and backend API are implemented except for SCRAM > channel binding and CRL file support, it needs tests and documentation, it > does > not implement pgcrypto, it will be fixed to support whichever GUC strategy the > project decides on for multiple TLS library support. One bit of conclusion in this area is that at Peter E has argued in favor of having separate configure switches for each each SSL implementation instead of reworking things into a single, generic switch. The GUC portion is also pointing in the direction of having one set of parameters per implementation so as assigning default values is a no-brainer. Seeing the GUC portion changed. Even if this is not changed, there is always the point of assuming that the existing SSL parameters map to OpenSSL, and add on top of it the new sets. But that would be confusing for the user than renaming simply the existing parameters. -- Michael
signature.asc
Description: PGP signature
